State
Last updated
Was this helpful?
Last updated
Was this helpful?
A driver should be built to represent the state of the device or service it is abstracting.
User interfaces can bind to state to provide visual feedback
Logic can query state and subscribe to state changes to trigger further actions
Driver state is should always be considered public and as such, should never contain any sensitive information (auth details, access tokens etc).
Any authenticated user can read the state
Do not store sensitive material in state
A driver like a hash
Setting state self[:state_key] = 'value'
Reading state self[:stafe_key] # => 'value'
Logic can access driver state in the same way
Reading state system[:Display][:power] # => true
Setting state system[:Display][:not_recommended] = true
Logic might trigger a useful action by changing the state of other drivers directly, however generally it is recommended to use a .
All state values should be limited to objects that can be converted to JSON for transmitting over the API.
JSON compatible classes: nil, true, false, Hash, String, Integer, Array, Float, Symbol
Objects that respond to: #to_json
or failing that #to_s
will be called when sending over the API
Objects that don’t meet these requirements can be used server side and are sent as nil
over the API
All drivers can subscribe to their own state.
Logic can additionally subscribe to state of other drivers.
When state is applied it is checked against the existing value and subscribers are only notified if the value has changed.
Change detection doesn’t work if you mutate a variable.
Mutating complex status variables is not recommended as the variables might be being acted upon on another thread. This can lead to race conditions or worse.
The recommended method for updating complex state is:
Duplicate my_array = ['my', 'array'].dup
or {complex:['hash']}.deep_dup
.deep_dup
when in doubt
Update my_array << 8
Apply self[:my_array] = my_array
This can be achieved by using operations that create a new object