Gem file dependencies, naming, and transition plan

This describes how we get from the current mixed bag of HyperReact/Mesh gems to a consistent set of Hyperloop gems (and hyperloop-express js files.)

First the gem file dependencies:

  hyperloop-config
   ^            ^
   |            |
   |            |--------hyper-store
   |                         ^    ^              
   |                         |    |--hyper-component
   |                         |
   |                         |
   |--hyper-operation        |
   |         ^               |
   |         |               |
   |         |--hyper-model--|
   |
   |--hyper-rails (might use hyperloop config for control?)

###Notes

hyperloop-config gem

This just provides a standard way for the other gems to define config params that can be stored in a rails style initializer. It is never needed to be directly referenced in a Gemfile or require by the developer.

Version Numbers and Content

gem	version	notes
hyper-loop	0.8	initial release
hyper-store	0.8	initial release
hyper-operation	0.8	initial release
hyper-component	0.12	hyper-react 0.11 + pending fixes + compatibility requires (see below)
hyper-model	0.6	hyper-mesh 0.5.x + fixes + dependence on hyper-store and hyper-operation gems

Hyper-Component compatibility

The hyper-component gem will include 3 compatibility modes, determined by which file you require in components.rb.

• Hyperloop Standard: (require 'hyper-component') In this mode you will use the new hyperloop syntax for all names, macros etc. I.e. components are defined as subclasses of Hyperloop::Component or using Hyperloop::Component::Mixin. states are changed using mutate rather than the exclamation notation.
• HyperReact Compatibility: (require 'hyper-react') In this mode you can use either syntax, but you will get deprecation warnings, as this mode will go away. This mode will be provided as a bridge so developers can use Operations and Stores without having to make changes to existing components.
• DSL Only (require 'hyper-react-dsl') In this mode you will use the new syntax, however, the DSL will be limited to the base feature set provided by react.js. This mainly applies to states acting as stores. The advantage will be smaller payload size. Initially, this mode not exist but the code will be set up to support it easily in the future

In addition, we will make one more release to the hyper-react and hyper-mesh gems that simply pulls in provides the hyper-component and hyper-model functionality, plus a deprecation warning. The intent is that the next time you update these gems, you will get the warning, and will know to change to the new gem names.

Store and Operation interoperability

Stores depend on Hyperloop::Application::Boot, which is an operation defined in the Operation gem. So that you can use stores without operations, the store gem will define a very basic boot operation unless Hyperloop::Application::Boot is already defined.

Hyperloop Express

There is no gem here, just JS files. We will have two: hyperloop-express.js which includes hyper-component (and therefore hyper-store) and hyperloop-express-operation.js which brings in the Hyperloop::Operation class (but not the Hyperloop::ServerOp class)

To support this the hyper-operation gem will have a hyper-operation/client_only require file.

hyper-react gem -> hyper-component gem transition plan

To make the hyper-component transition we will

1. Take the hyper-react master branch, and refactor so that state management comes from the hyper-store gem.
2. Add deprecated methods for state.xxx! and export_state methods, that use the hyper-store mutate, and state scope: :class methods respectively. This will allow temporary backward compatibility with this older syntax.
3. Add a base deprecation method that tells you to update your gem file to hyper-component.
4. test, release and tag this as v0.12-hyper-react-deprecated branch
5. change gem name
6. set up so that you can choose to either require 'hyper-react' or require 'hyper-component'. hyper-react will have the behavior outlined in step #2, plus a base deprecation message saying to update require hyper-component. Requiring hyper-component will give you only new hyper-store state/mutate syntax.
7. release and tag this as hyper-component 0.12
8. rename the repo to hyper-component
9. leave a forwarding message at the old hyper-react repo

hyper-model gem implementation and release plan

The hyper-model gem should be basically compatible with the hyper-mesh gem. So users are warned that hyper-mesh is going away we will do a hyper-mesh 0.6.0 release that prints a deprecation warning so developers will know to switch gem names. (See the above hyper-react transition how this is done.)

The hyper-model gem will be implemented using Stores (for state) and Operations (for remote procedure call and broadcasting model updates,) but no other changes should be needed.