I'm currently spiking out XState -- it's not yet clear to me if it's going to help. I need to actually implement a mock UI to see if it's actually easier to work with. In the meantime, I've had another idea for shoring up the complexity of our UI. The idea is to add a post-processing layer to our data fetching queries that would shape the response into something flat and easily consumable to the UI. We could also cache these data reads so the postprocessing would happen infrequently, and this would actually increase our site-speed quite a bit as well.
Here's a bit of insight into the problem to better motivate what I am thinking. We have a proposal. On the proposal are tons of nested relationships, and some of these relationships even require calls to external APIs, which we are doing on the client. When a user sees a proposal page on our UI, much of the logic of the component is parsing through the proposal response to see which roles exist, if the role is a gnosis safe, which signers exist for the role, if the role's signatures have been complete, etc. Imagine instead if we pushed this work to the server, and responded with some nice flat structure on the UI that could be easily consumable.
Rather than writing a horrible hook like getRemainingRolesForUser we could instead have the response return a nice flat JSON like
To be honest, I'm not even sure if that is a good looking or useful data object, but thats besides the point. The point is that we could shape the response to be whatever we wanted so it better serves the needs of the UI.
Yes, this would take additional processing time, but imagine if we cached these results. It would be abstracted away too. The queries would look something like this
I know we've also talked about how we can't cache stuff because the gnosis signers list might change, so we have to be checking that list of signers from the gnosis API on each request. I think this is nonsense and is shortsightedly limiting the capability of our architecture.
Maybe what we could do to remedy the gnosis API thing is to set up a background queue and have it check the gnosisAPI each night to refresh the signers in case they have changed. It would hit the API and check for changes, then invalidate stale proposals or roles or whatever else. If the user notices that the UI is incorrect, we can offer a button to manually refresh the cache. I really think it would reduce the complexity of our app if we didn't have to run a hook on the client to fetch gnosis details every single page load.
Anyways, these are some late night thoughts that I wanted to write down so I don't forget them.
I'm currently spiking out XState -- it's not yet clear to me if it's going to help. I need to actually implement a mock UI to see if it's actually easier to work with. In the meantime, I've had another idea for shoring up the complexity of our UI. The idea is to add a post-processing layer to our data fetching queries that would shape the response into something flat and easily consumable to the UI. We could also cache these data reads so the postprocessing would happen infrequently, and this would actually increase our site-speed quite a bit as well.
Here's a bit of insight into the problem to better motivate what I am thinking. We have a proposal. On the proposal are tons of nested relationships, and some of these relationships even require calls to external APIs, which we are doing on the client. When a user sees a proposal page on our UI, much of the logic of the component is parsing through the proposal response to see which roles exist, if the role is a gnosis safe, which signers exist for the role, if the role's signatures have been complete, etc. Imagine instead if we pushed this work to the server, and responded with some nice flat structure on the UI that could be easily consumable.
Rather than writing a horrible hook like
getRemainingRolesForUser
we could instead have the response return a nice flat JSON likeTo be honest, I'm not even sure if that is a good looking or useful data object, but thats besides the point. The point is that we could shape the response to be whatever we wanted so it better serves the needs of the UI.
Yes, this would take additional processing time, but imagine if we cached these results. It would be abstracted away too. The queries would look something like this
I know we've also talked about how we can't cache stuff because the gnosis signers list might change, so we have to be checking that list of signers from the gnosis API on each request. I think this is nonsense and is shortsightedly limiting the capability of our architecture.
Maybe what we could do to remedy the gnosis API thing is to set up a background queue and have it check the gnosisAPI each night to refresh the signers in case they have changed. It would hit the API and check for changes, then invalidate stale proposals or roles or whatever else. If the user notices that the UI is incorrect, we can offer a button to manually refresh the cache. I really think it would reduce the complexity of our app if we didn't have to run a hook on the client to fetch gnosis details every single page load.
Anyways, these are some late night thoughts that I wanted to write down so I don't forget them.