Think of state as data. Yes, state can be changed by the intermediary of actions, but it only represents a certain data at a given time. Nothing more, nothing less.
On the server, my current general thumb rule regarding state consists in simply spreading it across typical Services fields as we know them from frameworks in a such fashion.
local ShipSystem = {
PlayersShipMap = {}
}
function ShipSystem:AddShip(plr, ship)
--It obviously requires checking if there's already one as well as numerous
--few others stuff. Let's just keep it there for the sake of simplicity,
--shall we?
self.PlayersShipMap[plr] = ship
end
...
return ShipSystem
Rodux is a good example of a way to manage state, especially when speaking about user interface. Its principles goes as the following, single source of truth, state being read-only and finally changes by the use of pure functions.
After reading that and experimenting things with it for a while, I’ve been thinking about expanding the use of Rodux to not only the user interface, but why not do the same for really anything involving some sort of state? In a such way, that the Server would have its own store and actions would be done by Services as shown above. (The only difference would really be the fact that the action would be dispatched instead of directly doing it like that)
Now, I’m not a webdeveloper by and means and I understand how some of you may see webdevelopers as a plague on Roblox for whatever reason. However, this is not the point of this article, so I’ll have to kindly ask anyone whose sole argument is the fact that it’s a “webdeveloper stuff” to skip this article. I should’ve perhaps put that above.
So I’m essentially looking for the best way to represent the state, but if possible, I’d like to know why it wouldn’t be a good idea to use Rodux in this case for doing a such task on the server, because so far it seems to be what I’m looking forward to.