-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Christopher M Balz edited this page Aug 16, 2015
·
3 revisions
Welcome to the vibrashank wiki!
See https://github.com/christopherbalz/vibrashank#links
- Use a branch and pull request for every non-trivial feature and bug fix.
- For in-depth changes, read and understand the Architecture Priorities and Code Idiom below.
- When data changes, the app (built with this framework) will re-render.
- All data goes on the One Cursor to Rule Them All.
- Local state is not supported, in favor of keeping everything on the Cursor.
- This enables complete back-button operation and re-hydrating apps, and avoids a lot of excess code, in favor of re-renders.
- Avoid React internals
- Okay to sacrifice some performance for this goal, in the view that eventually, React will expose the needed facilities.
- Use CSP channels, as in go-blocks or as in the module
js-csp
, to organize client-server communication instead of, for example, Flux.core.async
will probably work well for this.- Flux introduces a lot of boilerplate and is more of an object-oriented concept that doesn't fit as well with data-flow architecture as channels do.
- Avoid "promise"-style and "then"-style api's in favor of asynchronous channels.
- This will keep the code simple, shorter, easier to read, and easier to debug (see
js-csp
).
- Try to re-use existing tools wherever possible: For example, perhaps we can use Reagent as the React interface, saving us time to build that. The challenge with that approach would be integrating the Cursor.
- All code is in ClojureScript.
- Objects are okay, but always re-compute (including re-render) instead of store, where possible.
- Use jsx if possible, but never inside of complex JavaScript: Move complex javascript out into its own files.
- Follow Clojure conventions where possible.
- Because native ClojureScript is still in its infancy, we'll use the Java-based ClojureScript.