[FEATURE] Enhancement: Reflect application state in URL for better shareability

[azr-arch]

Description

Currently, the application uses React state to manage the selected language and other filters. This works well for a single user session, but it makes it difficult to share a specific state of the application with others. For example, if I filter the issues by a specific language and want to share this view with a colleague, there's no easy way to do that.

My suggestion is to reflect the application state in the URL using query parameters. This way, when a user selects a language or applies other filters, the URL will update to include these selections. Then, this URL can be shared with others who will see the exact same state when they open the link.

For instance, if a user has selected ‘JavaScript’ as the language and is on page 2, the URL would look something like this: https://easy-fix.vercel.app/?language=javascript&page=2. This makes it easy to share a specific view of the site, as all the selected values are included in the URL.

This can be achieved using React Router or without react router (by using window.history but this will not be clean as router approach).

This approach is often used in web applications to make them more user-friendly and shareable. I believe it would be a valuable here.

Screenshots

No response

✨ Browser

Google Chrome

Checklist 🚀

• [X] I checked and didn't find similar issue
• [X] I have read the Contributing Guidelines
• [X] I am willing to work on this issue (blank for no).

[fekete965]

It would be a great addition to the site. I had a similar idea and wanted to propose the following step-by-step plan:

1. Add react-router to the project
2. Fetch the data and store it inside the router's context using loaders, this approach would probably make the context provider obsolete.
3. Since the provider is not needed anymore, it can be removed but the filters need to update the query params
4. Inside the loader we also need to parse the query params and only send the relevant one to the API

[azr-arch]

yeah, lets just wait for @vatsalsinghkv perspective on this!

[fekete965]

I love your idea, hopefully, you can carry on with it 🤞 :)

[vatsalsinghkv]

@azr-arch that's good but we gotta use router for it, should we consider migrating to nextJs so we can have one home-page too, telling about our product and contributors @fekete965 ?

[azr-arch]

@vatsalsinghkv yeah, that would be good

[fekete965]

@azr-arch that's good but we gotta use router for it, should we consider migrating to nextJs so we can have one home-page too, telling about our product and contributors @fekete965 ?

We could migrate the project to Next.js, but all the current contribution tickets must be done before we can do that. It would be unfair to move to Next.js towards the other contributors, especially those who wanted to contribute under Hacktoborfest. I can see there are a lot of issues picked up but nobody actually did anything about them and there are a few which doesn't make much sense. You could mark issues as inactive and redundant so the "important" issues can be focused on.

[fekete965]

This issue was @azr-arch's but I am not sure how much experience he has with next.js but migrating to next without actually using it should not be a problem. Once that's done, smaller migrations can be easily done.

If we are going to migrate, some of my current issues become irrelevant. I will keep stuff on hold for now. The only issue I could do in the meantime is about adding a storybook to the project and making sure every component is correctly rendered on both client and server side.

[azr-arch]

@vatsalsinghkv yeah, @fekete965 is right, we can just, use react router for now, and after the hactorberfest, when all issues are done, we should migrate then.

[vatsalsinghkv]

@azr-arch @fekete965 see, using state makes thing so fast, like no redirecting to page and pagination is smooth, for sharing we can create a share button for particular issue that'd copy the url of the issue to the clipboard, what do you guys think about that?

[fekete965]

There wouldn't be any redirect on the page. This is not an old-school MPA, we have a SPA in our hand which handles the client-side routing. Using the Link from react-router would also allow us to add query params to the URL without any redirect which is just as snappy as using a state.

[fekete965]

@vatsalsinghkv yeah, @fekete965 is right, we can just, use react router for now, and after the hactorberfest, when all issues are done, we should migrate then.

If we go ahead with react-router I wouldn't migrate to Next.js in the end but Remix. The migration would be seamless.

[azr-arch]

Its not gonna redirect anywhere, it will be like you are showing your states in the url, the page will be same, check this https://reactrouter.com/en/main/hooks/use-search-params

On Sat, 14 Oct, 2023, 10:04 pm Vatsal Singh, @.***> wrote:

@azr-arch https://github.com/azr-arch @fekete965 https://github.com/fekete965 see, using state makes thing so fast, like no redirecting to page and pagination is smooth, for sharing we can create a share button for particular issue that'd copy the url of the issue to the clipboard, what do you guys think about that?

— Reply to this email directly, view it on GitHub https://github.com/vatsalsinghkv/easy-fix/issues/54#issuecomment-1763034582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5M6Q43GZ42V2LWY6ADOZDX7K5KFANCNFSM6AAAAAA55EZTAM . You are receiving this because you were mentioned.Message ID: @.***>

[azr-arch]

I dont know much about Next, but i think it would be pointless, becauss there is no server side so couldnt use most of nextjs feature including SSR, isnt it?

On Sat, 14 Oct, 2023, 10:48 pm Bence Fekete, @.***> wrote:

@vatsalsinghkv https://github.com/vatsalsinghkv yeah, @fekete965 https://github.com/fekete965 is right, we can just, use react router for now, and after the hactorberfest, when all issues are done, we should migrate then.

If we go ahead with react-router I wouldn't migrate to Next.js in the end but Remix. The migration would be seamless.

— Reply to this email directly, view it on GitHub https://github.com/vatsalsinghkv/easy-fix/issues/54#issuecomment-1763055792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5M6Q6QXRBTT4W3PLXPF5DX7LCO7ANCNFSM6AAAAAA55EZTAM . You are receiving this because you were mentioned.Message ID: @.***>

[fekete965]

I dont know much about Next, but i think it would be pointless, becauss there is no server side so couldnt use most of nextjs feature including SSR, isnt it?

At the moment we don't have our own server but if we would use Next.js or Remix, there would be a server involved that we can configure. We would be able to take advantage of SSR, SSG and ISR as well if needed. The application would be much faster and safer as we wouldn't expose any network call on the client side, everything will stay hidden, so nobody can inspect the code or the network tab to extract some ENV variables or tokens. SEO could be easily optimised. Request caching can easily implemented on the server side by using native fetch on the server side with caching time defined.

[azr-arch]

Sorry my bad!

On Sat, 14 Oct, 2023, 11:42 pm Bence Fekete, @.***> wrote:

I dont know much about Next, but i think it would be pointless, becauss there is no server side so couldnt use most of nextjs feature including SSR, isnt it? … <#m7244644280548040237> On Sat, 14 Oct, 2023, 10:48 pm Bence Fekete, @.> wrote: @vatsalsinghkv https://github.com/vatsalsinghkv https://github.com/vatsalsinghkv https://github.com/vatsalsinghkv yeah, @fekete965 https://github.com/fekete965 https://github.com/fekete965 https://github.com/fekete965 is right, we can just, use react router for now, and after the hactorberfest, when all issues are done, we should migrate then. If we go ahead with react-router I wouldn't migrate to Next.js in the end but Remix. The migration would be seamless. — Reply to this email directly, view it on GitHub <#54 (comment) https://github.com/vatsalsinghkv/easy-fix/issues/54#issuecomment-1763055792>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5M6Q6QXRBTT4W3PLXPF5DX7LCO7ANCNFSM6AAAAAA55EZTAM https://github.com/notifications/unsubscribe-auth/AS5M6Q6QXRBTT4W3PLXPF5DX7LCO7ANCNFSM6AAAAAA55EZTAM . You are receiving this because you were mentioned.Message ID: @.>

At the moment we don't have our own server but if we would use Next.js or Remix, there would be a server involved that we can configure. We would be able to take advantage of SSR, SSG and ISR as well if needed. The application would be much faster and safer as we wouldn't expose any network call on the client side, everything will stay hidden, so nobody can inspect the code or the network tab to extract some ENV variables or tokens. SEO could be easily optimised. Request caching can easily implemented on the server side by using native fetch on the server side with caching time defined.

— Reply to this email directly, view it on GitHub https://github.com/vatsalsinghkv/easy-fix/issues/54#issuecomment-1763092211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS5M6Q65DOZKHXJ2AFTGNODX7LIZFANCNFSM6AAAAAA55EZTAM . You are receiving this because you were mentioned.Message ID: @.***>

[azr-arch]

@vatsalsinghkv any update on this ?,

[azr-arch]

hey can i work on this ?