Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A way to not reroute some url modification. #41

Open
ivanceras opened this issue Mar 9, 2018 · 3 comments
Open

A way to not reroute some url modification. #41

ivanceras opened this issue Mar 9, 2018 · 3 comments

Comments

@ivanceras
Copy link

Let's say if the user clicks on a button that opens a record, the code will open initialize and open a view, as an enhancement, the url is modified to allow users to share links, but then it will make the app do a reroute/setroute page then open exactly the same view.

So, is there a way to do this:

  • user clicks on a record, the program initialize and open the view, the url is then programatically modified for link sharing purposes <--- should not do a reroute.

  • user manually modify the url in the browser <--- should do a reroute to the pages.

@rtfeldman
Copy link
Owner

rtfeldman commented Mar 15, 2018

Sorry, I don't understand. Can you rephrase?

Annotated screenshots might help!

@ivanceras
Copy link
Author

In the elm-spa-example, clicking on the tags will not change the url since href is javascript:void(0) and also since onClick (SelectTag tagName) which execute the corresponding update on the models. There's nothing wrong here, except the user can not share the url to other user that is looking on the content for that active tag.

Meanwhile building a complex app such as this user-friendly database-interface, and one of the goal of the app is that whatever the user is looking at, he can copy the url and share it on chat with other users and they will be seeing the same content.

Take notice of the clicking on between tabs inventory, actor and category clicking on those tabs will update the Model and in turn the view.

There are 3 possible ways the user could see the same content:

  • (1) Clicking a button will execute an elm update .. Cmd Msg and display the corresponding view (very fast, since the data has already been loaded from the server).
  • (2) Right clicking open in new tab the href will display the same content, the difference is that the app will initialize from the beginning, fetch data from the server and initialize the view and will display the same content ( slow ).
  • (3) Typing / Copy pasting on the URL will load the app from the beginning, fetch data from server and initialize the view and will display the same content ( also slow ).

Item (2) and (3) works perfectly, but item (1) has a lot of complications since:
After the model and update has been executed I added a

model =>Cmd.batch [Route.modifyUrl ... ]

to change the browser URL so that users can share the new url based on the new content he is looking.
The side-effect is that it seems (3) is triggered, causing it to load afterwards, the reload( triggered re-initialize) is very subtle, since it displays the same view so there is no jumps in between view, but take notice of the loading-indicator at the top.

TL:DR;

If you could make the elm-spa-example to change the url when clicking on tags to something like
http://localhost:4000/#/tags/dragons while showing the new content without triggering a reload, then that would solve my issue.

@dwayne
Copy link

dwayne commented Apr 23, 2024

@ivanceras I solve this exact problem on the profile page which has the article tabs. When you click the tabs the URL changes so you can share either URL to open the page on that tab. At the same time, when on the page and clicking the tab that page doesn’t reload.

For e.g. Maksim Esteban My Articles and Favourited Articles tab.

Additionally, I could exploit the same technique on the home page with the tabs and the tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants