Quick iterative development
For client-side JS apps, of varying scales, I'm currently liking node
, as a development platform. npm/react-slingshot
provides the basis, making good tooling decisions.
With hot reloading
, and mocha
, I have very quick cycles of iterative development, mostly driven by TDD
. After hitting "save" in my source file, the project is fully-tested within a fraction of a second.
I say "mostly driven by TDD", because it takes a lot of coding discipline to make everything
pre-fail and then have a testable implementation. For example, UI elements and behaviours need to be mocked, or operated upon in a non-browser environment (like enzyme
). I also relax my TDD discipline if I'm exploring new tools or patterns (i.e. breaking things creatively).Example: Ticket Finder
I usually provide a screenshot with each post, so here's a mobile-first
SPA (single-page-application) I made with react
, and the above-mentioned OS modules.
It queries a RESTful API service
, via a hosted proxy
to eliminate CORS problems (that is a nuanced decision, which I hope to write about soon, or provide links). The UI is snappy, filtering instantly. All the API access is asynchronous, using an isomorphic-fetch
The interface is fairly conventional, adopting an always-present results stack
that defaults to 'all results', so you start with something interesting to browse. It has a clean interface
(left screenshot), with the filter
hidden away until needed (middle screenshot).
Results are filtered live
(like a Google search), with n results
shown right alongside the "Search by Name" box, which gives mobile users an indication of how well their search term is working ("0 results" lets them revise it before scrolling down for disappointment!). The stack is paged
, which reduces the downloading burden.
Further filtering is available via the drop-down lists, which get their options from the 'Search by Name' results, to avoid frustration. If any criterion is not provided, we assume not to filter by it.
User actions are guided. For example, the primary actions
are green buttons, used sparingly: "More" and "Get Tickets". Blue buttons blend nicely with the theme, whose base colour can be tweaked with a single change to a line of SCSS (less
). We didn't use Bootstrap here; the CSS was trivial enough.
The event tiles use the image assets that the API provides, and overlays gradients and text in a way that makes them readable, regardless of content.Designed for failure
The client detects if the API is not available, along with three other fail conditions, which result in a friendly note in the app. With more time, a wish-list would include offline client-side storage
of data, with appropriate warnings. We'd do this with 'interfaces' to abstract the service (example: http://chimera.labs.oreilly.com/books/1234000000262/ch04.html#interfaces
This project-let led to some suggestions for improving the mobile experience with some API tweaks, and an image service.And finally...
This little project, although it looks very simple, uncovers many developer decisions. Given that the client-side code is loaded via Webpack, I opted to use ES6/7
features, transpiled by Babel
. This makes the redux
'immutable' coding much more concise and maintainable, due to its syntactic sugar for object deconstruction
, and object spread
. I also like the ES6 modules
and variable scoping, which help with the separation of concerns.
This, along with TDD, inspires confidence in the process. I think it would survive the maintainability test, which is successful if one can return in a month or two, and still know how to maintain the project.