Home

Welcome to the vibrashank wiki!

Project Links

See https://github.com/christopherbalz/vibrashank#links

Contributing

• 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.

Architecture Priorities

1. When data changes, the app (built with this framework) will re-render.
2. 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.

1. 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.

1. 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).

1. 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.

Code Idiom

• 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.

Build and Infrastructure

• Because native ClojureScript is still in its infancy, we'll use the Java-based ClojureScript.