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, and (according to Policy) that state will change all on its own when the underlying 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.

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

• Use Models and/or Stores and add your business logic into either as class methods
• Encapsulate your business logic into Action classes that mutate Models and/or Stores

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. If you want to invoke a secure API on another server then you are out of luck as you need to build some boilerplate scaffolding so that the call comes from your server and not your client - you know how to do this"

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.