UniversityDAO / udao

The official UniversityDAO DApp repository.
GNU Lesser General Public License v2.1
4 stars 4 forks source link

Card viewing problem with Redux #76

Open austin-davis1 opened 2 years ago

austin-davis1 commented 2 years ago

@jagger-harris brought this to my attention:

If a user clicks on a card and then goes to refresh, the site will land on an empty page (nothing has rendered).

Reason: Currently when someone clicks a card we push this cards data into the Redux store. Then, we route to a view proposal page that will take whatever card data is pushed into redux and display that data. The problem is, the Redux store will clear out completely upon page refresh (ie app re-render). So then we are still on this view proposal page, but Redux has no selected proposal now in its store and thus the page is completely gone.

Potential fix: One way to solve this problem (and eliminate the need for Redux) would be to create a mapping of Routes in app.jsx. For instance we would grab all the proposal data for the site (getAllProposals function) and then map each one of these values to a single route. That way we create an individual (and unique) URL for every single proposal we have. If someone is on a specific proposal (which has its own specific URL) and they refresh, they will end up back on that same page.

I do think it's neat using Redux to create one singular page that just filters what we see, instead of making a new page for every single proposal via a mapping. Maybe there could be a way to preserve Redux state through a refresh so that it doesn't get lost in the process? Just another potential idea.

oslfmt commented 2 years ago

If I'm understanding your potential fix correctly, we would create a static mapping of each proposal to a specific URL. Like you mentioned in your last paragraph, we would have to make a new page for every single proposal, and further we'd have to update this every time for when a new proposal is created. I suppose there is a way to automate this with a loop that runs on each render and creates all the necessary routes based on proposals fetched.

That would work. I think there's a more canonical solution though with URL params, and matching them: https://reactrouter.com/en/main/getting-started/concepts#match-params. I haven't looked into how this would work, but when I first saw Jagger's implementation of the view_proposal route where you could individually look at a proposal, this is what struck me as what we needed (we see it all the time in urls the ?id=xyz).

In fact, that may be what you are talking about Austin, just using different technique, but similar idea.