An issue with React Widgets DateTimePicker

When you have the fix to a problem, but don’t know the root cause of why that problem is happening, you have two choices:

  1. Accept you have a solution, and move on, or;
  2. Accept you have a solution, and figure out the cause of the problem.

The problem is, #2 takes time. And that might not be time you have currently.

Dwelling on some problems is not the best use of my time in my current position.

So here’s my problem, and a solution, but I cannot offer you the root cause to this problem. Nor is it the defacto solution, I believe.

Using React Widgets DateTimePicker

I guess you’re either the kind of developer who creates everything themselves.

Or you first try using other people’s.

I wanted a Date Picker, ideally with time, and I would like it to be hooked up to Redux Form.

The good news, Redux Form already works nicely with React Widgets. See the previous link for a decent tutorial. And this code sample.

As a result, I can quite easily add in a Date Time Picker that’s hooked up to my Redux Store. This is good. It pleases me.

It also allows me to start laser focusing my A/B tests.

date-of-birth-as-a-timestamp
You’ve never A/B tested unless you know for sure customers don’t prefer timestamps.

But joviality aside (wait, that was humour?), I did hit a problem along the way:

react-widgets-calendar-size-issue
That’s not so good, Al.

There is a quick fix to this.

Add in a local (S)CSS style:

redux-form-datetime-picker-react-widgets
Better

It’s good, but it’s not quite right. Good enough for me to continue, though has been firmly lodged into the ticket queue under ‘improvement’.

Here’s what it should look like:

react-widgets-datetime-picker-proper

So there you go. Hope it helps someone. It’s unofficial. It’s not the real fix. Any pointers appreciated.

How I Fixed: uncaught at check call: argument [object Promise] is not a function

Earlier this month I started dabbling with Redux Sagas as an alternative to Redux Thunks.

At the time I was highly skeptical – largely around whether re-writing a significant portion of my JavaScript was good use of my time, given that I had no prior experience with generators, and that conceptually sagas sounded pretty hard.

But I kept hitting issues with Thunks. They just seemed so cumbersome, and error prone. I found writing tests for them to be painful, and adding in the Redux API Middleware made that even more complicated.

Ultimately, switching to Redux Saga has been one of the highlights of my current project. I love it. Every problem I have had so far has been made easier through the use of sagas.

But today I hit on a problem I haven’t seen before:

This is a generic version of the code I am using:

I have highlighted the problematic line.

The issue here is that the error in the browser is fairly cryptic. It took me digging into the source code to figure this one out.

But actually the issue is really simple to fix.

The highlighted line above should be :

I was calling my function myself, and then passing the promise on to the Saga… whoopsie daisy.

 

 

7 things I learned adding Jest to my existing JavaScript boilerplate

Here are 7 things that I encountered when trying to add Facebook’s Jest to my existing React JS project.

This project was initially based on Corey House’s boilerplate – React Slingshot. There was nothing wrong with the test setup the boilerplate provided. I just wanted an excuse to try Jest.

1. Jest doesn’t play well with importing stylesheets

Here was the code I was using:

And the associated Jest output:

To be fair, the output looks a bit nicer in the terminal.

Removing the stylesheet line:

Now commented out, all passing:

2. Tests live in the  __tests__ directory

The tutorial link doesn’t make it immediately obvious that the location and naming of your test files has an assumptive default config:

The boiler plate I am using has the test files in the same directory as the component itself. I followed the boiler plate pattern first, and it didn’t work.

I was confused why my tests wouldn’t run:

Tests need to go in a  __tests__ directory, unless you are a regex ninja.

If you do want to overwrite it then you can update your  package.json with extra config:

I went with their defaults.

Now also note, you wouldn’t have this problem if you had read the landing page and the Docs link. I made the mistake of going direct to the Docs link via Google.

3. You may need to rename things

In React so far I have seen files named like either  thing.jsx,  or  thing.js. I’ve never seen anyone use  thing.react.js.

However, the Jest docs use this convention.

So, having made two mistakes already, I made the switch myself.

Tangible benefit: None(?)

4. Jest ran existing tests just fine

This one threw me.

I had an existing file left over from my purge of the boilerplate demo site. I manually deleted the files as I worked my way through and replaced the boilerplate parts with my own.

One such file that was left was a utility class called  mathHelper.spec.js 

Jest ran this just fine:

5. Snapshot Testing is a really smart idea

You are kidding me.

Another concept to learn?

When will this learning ever end? Never. Get reading.

Actually though this is fairly simple to understand, and incredibly beneficial.

An example illustrates it best.

Let’s say I have a very basic component:

And a really simple test:

The first time I run the tests with npm test then Jest will create a snapshot of how this page is expected to look:

And the test output:

Then, should you make a change to your component in some way which causes the output to change:

Then re-run:

Again, it looks nicer in the console.

6. You probably want an alias for updating snapshots

Here’s what I use, feel free to differ:

Every time you make a change to your component you likely need to re-update your snapshots. Having an alias is better than the alternative of typing out morse code.

7. There are concerns I only found out about after reading the Snapshot announcement blog post

Dropped in at the bottom of the blog post announcing Snapshot testing is some notes about forthcoming improvements.

This one caught my eye the most:

  • Mocking: The mocking system, especially around manual mocks, is not working well and is confusing. We hope to make it more strict and easier to understand.

Thankfully I did this migration on a new git branch 🙂

How I Fixed: Redux Form onSubmit Proxy Object

It’s late, I’m tired, but no excuses, this took me about 45 minutes to figure out even with the documentation.

The problem:

I wanted to use Redux Form (v6.0.5) to handle form submissions for a simple login form.

I could get the form to render, and submit, but when I submitted my data, rather than getting back the JSON data as expected, instead I got a funky proxy object:

Annoyingly now I cannot reproduce the issue that made the Proxy object appear in the first place, but here is sample working code that fixed the issue:

And the login form itself:

There is a section on this in the documentation, but for the life of me, I couldn’t get my head around it.

All I know is, it seemed to like it more when I switched my LoginForm from a class to a function. But as I say, when I tried to revert my changes back to write up this blog post, it worked as a class all the same.

Hopefully this saves someone some time in the future.

How I Fixed: Uncaught ReferenceError: dispatch is not defined

It’s always a fun time when you hit an error, and you google it, and there’s no #1 result for a StackOverflow post, where someone far smarter than I can ever hope to be has already encountered, resolved, and shared their fix with some other unfortunate soul.

You mean I have to engage my brain and think? World, you can be cruel.

Anyway, tonight’s error (or one of them) was this :

It had me stumped for a while. This is a React app – based on a starter project. So, more than likely, this was my goof.

Anyway, I had myself some forethought and had followed the convention of adding  PropTypes to the class I am working on.

See if you can spot the mistake:

Given that apparently,  dispatch is not defined, I figured I would add it to the  propTypes and see what kind of thing either was, or was not being passed in.

That led to a new error. Which is good and bad.

Func, Not Function

It means what I did had some noticeable impact, but not the kind of impact that implies it’s resolved:

Weird.

Looking back over the  propTypes I suddenly remembered, it’s not function, it’s func. This caught me out last time.

The error could be nicer I guess.

Updated, saved, and thanks to hot reloading, that error had gone before I’d tabbed back to my browser.

Cool.

But the problem wasn’t yet resolved. Actually, at this point I’d essentially made little progress in solving the problem.

I had confirmed dispatch was a function though:

Looking at the problem code again:

At this point I knew this was my boob for sure, and likely the error was staring me right in the face.

So, I did what any code goon would do, and I stuck in a  console.log to figure out what the heck was on the props . In a second, you will see why this should have been obvious:

Which output a bunch of stuff which is quite hard to copy / paste in.

Anyway, it turned out on the props  was actions, which just so happened to contain the output from the function I had already declared:

doh!

RTFM Chris.

So I could update the call to:

And what-do-you-know?! It worked!

Obvious, in hindsight.

By the way, I appreciate to any season React devs that this is likely a big “durrrr” moment.

Hopefully it saves someone a headache somewhere down the line.