fruktkartan
Opening a tree should center the map on the tree
Click a tree at the edge on the screen.
The map will zoom in if needed (as intended), but is not recentered (as it should be), meaning that the tree may end up outside the screen.
~This bug only affects the first tree opened, meaning that this is most likely a Vue reactivity problem~
For me, i get the feeling that it is not only the first tree (in any meaning), but rather that it does not recenter correctly if needs to also zoom.
@quite Oh, you're quite right! Then the issue is more likely with the Leaflet lib. I'll see if I can find a work-around.
See you tried to fix it there on master? Hm, but doesn't seem to have worked, looking at https://master--fruktkartan.netlify.app/
Btw, did those last commits on master bring back the trailing /#/ in the URL path? I mean, so that it is present also on "main map view", but not needed? Because on current production site, vue3 (?) finally helped getting rid of it.
It's a very good thing to have gotten rid of that. But I also had trouble with getting Firefox to actually "forget" that there no longer is any /#/. Firefox stubbornly somehow redirect from https://fruktkartan.se to https://fruktkartan.se/#/ -- and it would not show our new vue3 site! -- until I blew up the caches (including visited site history). Ctrl-Shift-R did not help.
I now worry current master is bringing it back? (I have not deployed that to production)
Yes, I reverted to using the # here: https://github.com/fruktkartan/fruktkartan/commit/53a86fac7f15a5c68c826902f47a67498cbfea62
This solves https://github.com/fruktkartan/fruktkartan/issues/109
There is probably a way around this (I don't know the ins and outs of the Vue router), if you want to read up a bit and have a go at it (though using the url fragment to emulate routing in static SPA's is pretty standard behaviour on the web, I think)
On the other hand, if we merge the API and the frontend app to one SSR repo this will be solved, as the former version seems to work just fine in SSR mode
Too bad. But feels like getting the routing to work at least as before is important. So I'll deploy this to prod.
On the other hand, if we merge the API and the frontend app to one SSR repo this will be solved, > as the former version seems to work just fine in SSR mode
Are you saying that will get rid of "fragment-routing" all together, and it'll all be traditional URL paths? But that also requires deploying somewhere else right?
Are you saying that will get rid of "fragment-routing" all together, and it'll all be traditional URL paths? But that also requires deploying somewhere else right?
Yes, excatly.
But maybe we should focus on this Server-Side-Rendering if so?
I think that would be good anyway:
- it would let us unify some business logic (like tree types, etc)
- it would be cheaper (one server, that does not need to be any bigger than what currently runs the API)
I'll have a look at it!