Part 1: Stop writing mapStateToProps, start using declarative models
After you learned React, you probably went through a phase where you said, “Ok. Love it. How do I start using this in my own project immediately. How do I know I’m doing it right?” You know, like the pros. What setup are they using? All the examples you saw online were seriously watered down To-Do lists. You learned how to create a single Redux store to manage state. You remembered how easy it was to write $.ajax statements to update your UI, if necessary. You looked at GraphQL and thought, “For real??? That’s where this is all going?” and thought there had to be an easier way. Anyone?
When you learned REST, it was so simple and beautiful. You finally understood the difference between GET and POST, and understood the vision of the original mothers and fathers of the Internet. In any language, we can create, read, update and delete remote resources across websites and even on our own, handle authentication and show people their data. Sites can be truly interconnected. And all you need is a web browser! What a deal!
You became super excited seeing powerful frameworks such as AngularJS, and thought, “Great. These people have it all figured out, and I get to benefit from a team of solid Google engineers to write my own codebase for me. I’ll inherit their opinions and findings and benefit from their hard work, and get a prototype of my own idea out using their library. Awesome.” When you saw React, you thought, “Ok. This! This I can do!” The idea of state was so easy to understand, and the idea of building a tree of compartmentalized components made total sense. Not to mention you now have the unstoppable power of Facebook engineers at your fingertips.
All you had to do was completely gut whatever you had previously built, start learning ES6 from scratch, learn several if not dozens of new tools and frameworks to get your first state-manged button on the page. You may have figured out that a lot of people who are building single page applications are doing the same thing. They’re using Webpack with a series of loaders which transform their ES6/7 code into cross-browser-compliant JavaScript, and almost always use a combination of React, Redux, ReactRedux, andReactRouter to begin putting information on a page and navigate around.
If you’re like us at Avail, and you chose this route, you found MOST tutorials online help you get here. They showed you these tools were needed at a minimum to get your site working the way you’d expect. But one important piece seemed to be almost entirely missing. Where do I put my fricken models? How do I keep track of them? If you’re looking to find out how the pros are doing that, you’re on your own, I’m afraid. (**cue ominous lighting OR ARE YOU!?**)
Avail engineers are on the front lines, boots on the ground, handling dozens of dynamic form fields, dozens of unique API endpoints just to support our front-end, which we recently completely rebuilt into a single-page application. When you’re building an MVP, there are pretty much no rules. That’s where JavaScript comes in handy. It is the goddamned Wild West, especially today. You get the data on the page, you make sure it doesn’t break for the most common use cases. You let the users tell you what’s wrong with it later.
You do this until it doesn’t make sense to do anymore. Until you need to go from a team of one engineer to several, or several dozen, and no one is going to understand your spaghetti nonsense. Until your feature-packed (yet highly focused) front-end is a maintenance nightmare. Until you fear the thought of getting sick for more than a few hours because no one will be able to understand how to decode your work.
These problems were solved a long time ago with frameworks like Ruby-on-Rails. Everyone could agree on a specific way of performing very common tasks, implementing common functionality. This is one of the benefits of an opinionated framework. Less configuration > more meat and potatoes > faster results. You want to render a list of your books in a certain category you made up? That’s the easiest thing you can do in Rails. Want to implement user accounts with Twitter login? Of course you can do that in 15 minutes with Rails. I loved this and couldn’t believe it was so easy. It seemed the people working on Rails had some benevolent dictator who only cared about how to make things easier for me, and improve my experience as a young engineer. They thought of everything! All you had to do was sip the Rails Kool-aid, which I was happy to do. Coming from a PHP background, having built hundreds of Wordpress / one-off sites by 2013, I was parched for some opinionated Kool-aid.
What I’d like to offer is a sip of opinion to a tired, thirsty developer. I want to introduce the solution that has made us extremely fast at Avail, able to release new features without wasting time coding the same thing over and over again. I’ll ask you to reject a few sacred cows you may have picked up along the way in the journey described above. In return I can show you how API requests should have ALWAYS worked in React, how forms should have worked since the beginning, how to create an MVP like it’s nothing of a challenge. Avail wants to turn your front-end into the least complicated part of your product. You will feel the same magical feeling you felt the first time you submitted a form to your backend, and saw data persisted on the next page, and know you created something from scratch. You will sleep better at night knowing you’re not making this stuff up from scratch, and you’re finally handling data correctly, the way it wants to be handled. The pieces are already all there. We were so close.
If you’re thinking you’re going to need to write out URLs or manually write AJAX requests, reducers, actions, action dispatchers, you’re thinking you need a better saddle for your horse, and Avail is about to instead park a Tesla Model S in your driveway.
To see how, I’ll dig into what ReactiveRecord actually is in Part 2. Please read on or feel free to tell me a story of yours in the comments.
Continue reading the parts of this series below:
