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
Problem Statement #251 was solved using #264 wherein the routing system provided by nextjs made it difficult to pass query parameters around. The solution to work around this (the marshaling of query parameters) involves using localstorage to statefully route the user to the correct page. This may be the cause of issues such as #548 (and potentially other undiscovered issues). Further, having statefull
routing makes it difficult to know which server is being used during debugging - this approach to routing is not intuitive and another developer needed clarification. I personally ran into this issue even when I had set an environment variable to force the app to use a particular server.
Proposed Solution
Implement the logic of the router to be stateless. The benefits are two fold:
better cross-browser support (we don't need to depend on different ways browsers implement their caching)
more intuitive routing (user's have a straight forward way to know which server is being pointed towards)
easier debugging
Details
I suggest the following investigations/ideas:
the use cases behind switching servers (e.g. do we need to switch between qa and production servers at runtime or can we implement this as environment variables or initialization config?)
investigate the nextjs routing problem (outlined in fix typo #258)
use a different mechanism other than query parameters?
The text was updated successfully, but these errors were encountered:
Problem Statement
#251 was solved using #264 wherein the routing system provided by nextjs made it difficult to pass query parameters around. The solution to work around this (the marshaling of query parameters) involves using localstorage to statefully route the user to the correct page. This may be the cause of issues such as #548 (and potentially other undiscovered issues). Further, having statefull
routing makes it difficult to know which server is being used during debugging - this approach to routing is not intuitive and another developer needed clarification. I personally ran into this issue even when I had set an environment variable to force the app to use a particular server.
Proposed Solution
Implement the logic of the router to be stateless. The benefits are two fold:
Details
I suggest the following investigations/ideas:
The text was updated successfully, but these errors were encountered: