Sherlock: Writing a Single-Page Application in 2016
I’ve been working with single page applications for the better part of my career. A few times I got the feeling of riding on the latest wave on the best practices/paradigms. It’s a weird feeling: I know I can never tell for sure if this is right without a week or so of focused research and experimentation.
After a couple of months of writing a bunch of React-based SPAs, I knew some parts of my workflow had become painfully inefficient and I had to upgrade my knowledge and tools. I started reading more on flux and redux, and I felt excited, but a landslide of questions fell on me.
I made a list of things that I want to have a good grasp on how would I go about when using redux for a real life app. Issues that everybody found at some time. It’s where I look when evaluating a new paradigm/framework, places where most to-do examples don’t reach:
- How to do route management, history, paths, links.
- How to react to user input that triggers asynchronous requests, showing feedback to the user, like server-side validation or autocompletion.
- Loading an initial state with as few round trips as possible.
- Handling errors gracefully, and partial information retrievals (including pagination, lazy loading, caching).
- Debugging the state of the app, testing, reproducibility of bugs. Easy to read stack traces.
- Handling user sessions: credentials, login, server-side stored settings.
- Building the app for deployment, strict CSP, minimizing data to transfer, batching content for request optimization.
- Modularity and testability of components.
- Development time optimizations: fast compilation, tools for reloading (with redux, I want to have time traveling and hot module replacement), automatic lints and tests.
So I went shopping for cool projects using redux. I found a couple ones that were pretty interesting:
- davezuko/react-redux-starter-kit: Looks like a good choice for starting a new project and playing around.
- andrewngu/sound-redux: A SoundCloud client with quite a lot of features for a showcase project.
- react.rocks: A gallery of proof of concepts and small apps. A bunch of them use redux.
So after a few hours of delving into code, I felt like starting to code a medium sized app to test out redux in real life. As I’m a fan of bitcoin, I started coding a wallet, loosely based on bitcore playground, an app I helped write to showcase our bitcoin library bitcore.
Here’s the final result:
You can check out the code on github. I started with all the boilerplate set up by somebody else. I hate boilerplate. I liked react-redux-starting-kit because it seemed to have examples of pretty much everything I wanted. I rearranged the folder structure to be more semantic. To start answering some doubts I had, redux-simple-router was the way to go about how to manage routes and links.
To solve the async button state, I wanted to create a library similar to redux-forms. In essence, I’d like to have a namespace in my state that takes care of buttons and input that are blocked waiting on a request’s status.
As for loading an initial state, I’m still not sure about how to go about isomorphic pages. I guess the bitcoin wallet example is not enough, partly because it’s client side only (no user storage). I’ll add a little more functionality later (probably turn it into a hosted wallet like blockchain.info). Same with login, but the code in sound-redux convinced me that it won’t be a PITA.
I loved the speed of development with hot module replacing and time traveling. React errors are still ugly to debug sometimes; but it’s way better now with instant feedback. The redux-devtools can improve a lot but it’s great so far. I’ll probably add some features to manually insert actions, take snapshots of the state and loading them.
All in all, it’s been a cool experiment. I look forward to seeing developers’ workflows improve a lot with the hot module replacement technique. Also, I’ll keep working on features for Sherlock as a side project — it has a big wishlist and pull requests are welcome!
