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
currently, our app generally assumes in the type system that if you have an ID pointing to an entity (e.g. site or project) that that entity will exist in the redux store. this assumption worked on the web when the state of the store was very transient, but in a persistent & offline capable mobile app it no longer makes sense.
as it stands, developers need to just remember to do the right thing everywhere and not assume that entities are valid without checking, which is very contrary to how most things work in the codebase where the TypeScript types can be pretty reliable. this makes it really easy to mess it up.
i think the right approach to this is to first create tests that validate the desired behavior, and then consider also refactoring the code to have more honest TypeScript types. this could be a fairly large effort, so i expect that this issue would be a parent issues tracking several more manageable chunks of work.
i picked a medium priority to reflect the fact that developing new screens or modifying existing ones could be quite error prone for surprising conditions until we address this properly.
The text was updated successfully, but these errors were encountered:
currently, our app generally assumes in the type system that if you have an ID pointing to an entity (e.g. site or project) that that entity will exist in the redux store. this assumption worked on the web when the state of the store was very transient, but in a persistent & offline capable mobile app it no longer makes sense.
as it stands, developers need to just remember to do the right thing everywhere and not assume that entities are valid without checking, which is very contrary to how most things work in the codebase where the TypeScript types can be pretty reliable. this makes it really easy to mess it up.
i think the right approach to this is to first create tests that validate the desired behavior, and then consider also refactoring the code to have more honest TypeScript types. this could be a fairly large effort, so i expect that this issue would be a parent issues tracking several more manageable chunks of work.
i picked a medium priority to reflect the fact that developing new screens or modifying existing ones could be quite error prone for surprising conditions until we address this properly.
The text was updated successfully, but these errors were encountered: