As I mentioned previously, GeeryDev is back and it has been rewritten in React and Redux. Now, I must admit, that the list of things I did wrong continues to grow, but it was a pleasant experience. This post is a summary of the little things that I noticed along the way. For those who may not be aware. I was very new to React when taking up this project, but had used Redux for a little while. So there was a learning curve, but not too steep.

Also, I decided to start putting the source into Github in case anybody is concerned. Feel free to checkout the code here


Angular to React

This may be rudimentary, but it cannot be stressed enough. The traditional website building methodology is to create HTML (markup), CSS (styling), and javascript (browser interactivity), and load them nicely onto a page to create an experience. React’s methodology to front-end development is to write javascript. HTML, JS, even CSS can/(should) be written into your javascript modules, and this will be the big paradigm controversy even for a while to come with FE development. But lets go into this, because its paramount to the strengths (weaknesses if you want to see it that way) of React. So, as I try to explain the benefits, I will refer to the point that React is JavaScript, not so much that it has an amazing API. Do I love markup mixed with inline JS, binding context all over the place, and passing refs for DOM manipulation that might be trivial with jQuery? No. But I absolutely LOVE that everything is JavaScript and heres why:

Isomorphic Javascript

The server for geerydev.com is written in nodeJS. Now, isomorphic applications are nothing new. But, it is for me. This is the first time that I have every truly shared javascript modules between the client and server. As you can see here and here, I am really only sharing utility code. But a start is a start, and you could imaging a world where I share my mongoose models used by the server, with client models that are requested via ajax. This truly would allow for new levels of development speed, and who doesn’t love reusability. OR WHAT IF… We could share some service code that saved to different interfaces like MYSQL and LocalStorage. Interestingly enough, the geerydev client code is compiled with Babel and actually uses a more progressive version of Javascript than the server code, so you will see the that most of my utilities use an ES5 syntax.

Embracing ES6

Another thing that React seems to have done incredibly well is embrace the future of Javascript. Although, ES6 is not necessary to use React, it is much easier to comprehend when you embrace Javascript classes. In fact, extending React components becomes incredibly useful as you find patterns in your own applications. I was able to create a trivial Form Component that powers a significant portion of the new website.

Components/Containers

Nearly all the resources you find online today for React are going to make mention of the idea of components vs containers. I don’t think a lot of the examples and instructions are very good, or at least I think they could be more pragmatic. Or maybe I am just slow. Read more about it here, here or here. Components are dumb. They should not talk to your redux store or know anything about fetching data, but instead have all their props passed to them. I think this sets us up nicely to have our components become reusable

Containers are the parts of your app that deal with your data. These can be considered the “smart” parts of your application, or the ones that scaffold the layout by providing the data and passing it to components. These are the components that would be connected to a redux store.

Testing

Now, ignore everything that I have previously said. This is hands-down the greatest part of developing with React. Remember, React is writing javascript, and that means that testing our frontend is as easy as testing javascript. This may seam like some simple example of Modus Ponens, but let me explain. Traditionally, testing the frontend is not easy. You would need a browser to do some full testing and make sure that your javascript code is hooked up to the correct parts of the DOM, or that your DOM actually exists when it should. And often times this could get really messy, and only led to partial coverage at best. Now, testing javascript is much easier. Just perform actions, and ensure results. There is no browser, less mocks, less hacks, and less headaches. Since react renders your views, you can ensure your view and application logic are in perfect harmony by testing react components.

I have yet to dive into any of the more advanced testing frameworks like Facebook’s Jest, or AirBnb’s Enzyme. I will eventually. But, at this point, it has not been necessary. Working with mocha and jsdom has been a very enjoyable experience, and has handled most of use cases. You can find the geerydev tests here