Reactular – Or, How I learned to Stop Worrying and Love JS

Aka: Why modern Javascript frameworks are sometimes like characters from Eyes Wide Shut, wandering around at an upscale swingers party…

So far, using React has been a lot of fun- but I have noticed a bit of a learning curve.  The basics are nice and easy- particularly with the ‘create-react-app‘ utility.  If you haven’t used that, definitely check it out- it takes away almost all the setup of the application (webpack config, dev server, etc) and lets you get straight to the coding.

Usually, I’m one of those people that wants to build everything myself to understand how it works, but there are a couple exceptions.  Working with calendars and dates is one- I’ll always use a module/plugin for that.  My brain starts melting even thinking about trying to get that right.  Setup for JS frameworks is another.  We had to do all the config for an Angular 2 project through the release candidates and now into production and it was a bit of a nightmare.  No fault to the Angular 2 (sorry, just Angular) folks- their framework is awesome- but setting it up was not easy.

Anyway, getting a ‘hello world’ app going in React is great, but if you’re going to use it for anything beyond really cool UI components, things get tricky fast.  Some of that is managing/updating state- so relying on options like Redux can be a great option, but in this case, I wanted to see how far I can get on my own.  The test app I’m building (event tracker and commenting system) won’t be too complex, so it should be a good learning experience.  Keeping the functionality in one main container component and passing down anything (via props) that needs updating has worked well so far (and leaves good refactoring opportunities down the road).

Enough rambling- the point of this post is not React’s learning curve- it’s actually about how they’re all just JS behind the creepy bird mask and hooded cloak.  Sometimes, lessons learned in Angular can be applied (almost copy/pasted) directly to React.

Example: I have a filter option for events in my React app.  It’s in a sidebar that appears with every route view.  Click an option (current, past, all) and the sidebar events filter by date.  However, I didn’t want this to change the actual route- a user should be able to check out all the options before changing that, so the filter categories aren’t true links (in the React Router ‘Link’ sense)- they just set a context variable (this.filterType) and fire the method.

That last part is important, because React Router’s Link module comes with a nice option for ‘activeClassName’- set it to equal whatever class you want and when that Link is showing, that class is applied to that link.  I wanted the same effect, but my category headers aren’t Links.

Turns out, you can achieve this pretty easily.  I already have the filterType class variable.  I also know you can bind React’s className attribute to the result of a Javascript conditional.  I’ve also done something very similar in an Angular template file.  The code that makes it work in React (inside your element in JSX) is below. This one is on the ‘Current’ category filter button:

className={this.filterType === 'current' ? 'link-active' : ''}

In Angular (2) it might look like:

[ngClass]="{link-active: filterType === 'current'}"

Not exactly identical, but pretty close, and the idea is the same.  And pretty cool!  It really helps expose that it’s JS all the way down, even if it’s wearing a mask and wandering around the party telling people it’s HTML.  At the unmasking ceremony you get to see exactly what you got yourself into.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s