You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be cool to have a middleware that automatically makes all items in the store read-only. It'd be similar to the JS package 'deep-freeze', but probably throw errors on mutations instead of silently ignoring them.
Speed of implementation doesn't really matter here, since it'd only be a development tool.
Implementing this in Lua 5.1 might be tricky. Normally for a read-only table, I'd create a new table with __index and __newindex metamethods acting as a proxy, but then you wouldn't be able to iterate (or shallow copy) the table! In 5.2, Lua gained __pairs and __ipairs which would've helped here, but alas.
There might be one edge case in this implementation. Way back when I first used Redux, I would keep JS Promise objects in the store as a way to manage request status. Promise objects have internal mutability, which we might consider to be breaking the Redux paradigm, but because it's not observable outside of attaching a handler to the promise, I don't know if it is. If we wanted to support a use case like that, we'd need to make sure not to deep-freeze some objects, or force Promise objects to be userdata instead.
The text was updated successfully, but these errors were encountered:
It'd be cool to have a middleware that automatically makes all items in the store read-only. It'd be similar to the JS package 'deep-freeze', but probably throw errors on mutations instead of silently ignoring them.
Speed of implementation doesn't really matter here, since it'd only be a development tool.
Implementing this in Lua 5.1 might be tricky. Normally for a read-only table, I'd create a new table with
__index
and__newindex
metamethods acting as a proxy, but then you wouldn't be able to iterate (or shallow copy) the table! In 5.2, Lua gained__pairs
and__ipairs
which would've helped here, but alas.There might be one edge case in this implementation. Way back when I first used Redux, I would keep JS
Promise
objects in the store as a way to manage request status. Promise objects have internal mutability, which we might consider to be breaking the Redux paradigm, but because it's not observable outside of attaching a handler to the promise, I don't know if it is. If we wanted to support a use case like that, we'd need to make sure not to deep-freeze some objects, or force Promise objects to be userdata instead.The text was updated successfully, but these errors were encountered: