hyper-react
hyper-react copied to clipboard
StateWrapper doesn't do set_state when using []=
Here is a falling test case
it 'is supposed to work' do
k = Class.new {
include React::Component
before_mount do
state[:foo] = 'bar'
end
def render
div { state.foo }
end
}
expect(k).to render('<div>bar</div>')
end
The current implementation only update the cached Hash of the backing state. I think this is a bug and could be fixed by actually invoking State.set_state
.
/cc @catmando
yeah I just noticed this as well... i think perhaps the intent at one time was to give a low level direct access to the underlying react state hash, and there are methods for doing that
There are a couple of competing issues here:
-
@wied03 wants to separate out the non-react state extensions. These would go in a new gem that is now being tentatively called
hyper-store
. -
There is probably occasionally a need to reach down and just update the react.js state hash. This seems like a very infrequent operation, but should be documented as part of the DSL. Currently I think this was the intent of the
[]
and[]=
operators. -
An issue was just raised on gitter that the developer might like to reference the state name as a string. This might seem the same issue as 2, but the point is NOT to go around the reactrb goodness, but rather to just be able to use the name. I proposed that you can do this:
state('my_state_name
)to read the state, and
state!('my_state_name', optional_value)to update the state object or create an observer. This reads nicely i.e.
state.fooand
state('foo')are the same while
state.foo!and
state!('foo')` are the same.
the other approach might be to use the []
and ![]
to access the reactrb state object by string an then just have another method (like native_state
) to access the underlying state hash.
Note that using = for anything but the low level native state access is not a good idea since it leads to confusion for mutable objects. I.e. state.foo = 12 would lead you to believe that state.foo << 12 should also work. Hence we insist on state.foo! 12 and then state.foo! << 12 works.
Just to make sure, the second point
There is probably occasionally a need to reach down and just update the react.js state hash.
Do you mean this.state.foo = "nextFoo"
this kind of update, or this.setState({ foo: "nextFoo" })
? The former one is discouraged by ReactJS doc given that it won't trigger any re-render.