Evolution of Reactive UIs in Web Development: Best Practices and Implementation Guidelines
Table of Contents
Background
This provides background on current best practices in the area of reactive UIs. This is primarily focused on web UIs.
DONE Motivation
Related Notes
- file layout
- build tools
- design guidelines
- animations
Implementation
TODO Project Initiation
When talking through the expected requirements associated with a new feature the key goal is to ensure that the project owner, designer, and developer all use a consistent nomenclature when talking about interactivity. Historically that would have been in the guise of either event-driven design.
Broadly when looking at the web there are several key milestones:
- 1995 - 1998: design-driven: most of the development effort is moved toward addressing the limitations created by browser wars; there are few cross-platform
- 1999 - 2005: z-index: if interactivity is provided it's generally in the form of creating overlays or core features
- 2006 - 2011: jQuery: events, triggers, linting
- 2012 - 2014: CoffeeScript (and broadly other transpilers)
- 2012 - 2014: MVC, history, functional programing, transpilers
- 2013 - 2016: Frameworks: Ember and Angular:
- 2014 - 2018: Reactive UIs, immutability, typed javascript
Design
- what data is the user creating when they interact with our application
- what data are we persisting, obtaining, or reducing about the
- what UI will we be showing and hiding
- what are the routes that we expect would need to be supported; in particular when has the user performed a sufficiently interesting chance in view that they would need to have some management over the
- what is the sequencing that will be used to build out the feature
- what is out support matrix for the feature
- what are the existing libraries (for both display and functionality that we already have been provided
Examples
For each of the cases noted below we'll assume that we're going to have a multi-stage review, implementation, and status for the project.
- high-level feature requirements
- scoping feature criticality
- high-level task decomposition
- separating UI components from UI-enhancing features
Virtual DOM
- https://facebook.github.io/react/docs/glossary.html
- http://requirebin.com/?gist=5492847b9a9025e64bab
- https://gist.github.com/Raynos/8414846
For these examples we'll be using HyperText as the template language.
Site
- Site
- Header
- Footer
- Navigation
Generally we'll know about the core attributes we're expecting from a visitor (if authenticated or not, and if possessing a role or not).
TODO
Todo application: we'll begin by looking at the structures used across most of the implementations used in
For most of the implementation in TODO MVC we could begin by decomposing from just a UI basis without any interactivity. In this case we know that we'll have some of the components that are provided