Sunday morning summary

Stores and Models are basically the same things, they hold state. With a Store, the state will be made up of local ruby variables whereas with a Model the state will be linked to remote ActiveRecord models, and (according to Policy) that state will change magically when the underlying remote data changes.

Any change to state (in either a Model or Store) will cause any Component watching that state to rerender.

Actions change Store state or change the underlying Model data (which is like state). Actions can simply be thought of as class methods of Stores or Models or they can be classes in their own right if it makes sense to re-use them or if you want to chain Actions together.

If you prefer closer adherence to the Flux pattern, you can use Actions just like Flux events and your Stores can listen for them being broadcasted. Flux also insists that Stores contain Models and you can follow this pattern if you like but it is not enforced in Hyperloop as our Modals are accessed directly by our Components.

All the advantages of a nice neat architecture and you can follow the Flux pattern if you like. You have three options:

• Use Models and/or Stores and add your business logic into either as class methods
• Use Actions as Flux events and have Stores listen for them being broadcasted
• Encapsulate your business logic into Action classes that mutate Models and/or Stores

Stores and Models hold state, Actions mutate state. Actions cannot hold data. Stores can listen for and receive Actions as events. Components watch for state changes in Models or Stores and re-render when necessary.

------------ changes to remote Actions coming...

Now we have a thorny issue in that we want Actions to be able to invoke functionality that might not be available on the client. Of course, we could just say “hide your server functionality behind an API and simply call that API from within your Action and everything will work fine".

Luckily, we don’t want to put you through this hell so we have a way of automatically building an API for you so you can invoke a method on an Action (or Store or Model) as if it were local but the execution of that method will be done on the server as if it were an API call.

class GetRandomWord < HyperAction

  server_method :get_words do 
    @words ||= File.readlines("words_file.txt")
  end

  def execute
    get_words do |response|
        AddRandomWord(word: response.json.sample) if response.ok?
    end
  end
end

Models, Stores, and Actions can all have server_methods which behave this way.

The advantage of that would be that we just think of Models, Stores, and Actions as normal Ruby classes that we can use anywhere, knowing that sometimes they do little bits of magic and invoke their server_methods remotely.

Your business logic can be in the Stores or Models (if you like), but it makes more sense to encapsulate your business logic into Actions.

We take the need to API scaffolding out the equation and mix client and server code nicely yet make it clear that sometimes you are calling a method which is a remote procedure so we expect you to deal with the response.