[WIP] [RFC] Include profile options in hash

[tbsmark86]

Hi!

This is an Idea to address the various issues around this topic. For instance #26 #666 maybe #472 The Idea is to extend the &profile=fastbike value to be itself a nested parameter list. I'am doing this by replacing it with an URI.

The current minimal prototype will create a url like this: http://localhost:3000/#map=12/51.8751/12.3835/osm-mapnik-german_style,route-quality&lonlats=12.461743,51.882955;12.416908,51.840657&profile=bw%3Afastbike%3Fallow_ferries%3Dfalse Which when when loaded again will still have the allow_ferries set to false.

I've planed four different formats:

• <profile-name> - just like it is currently when options are not required
• bw:<profile-name>?<arg>=<value> - for a standard profile with options It's an url with a custom scheme - 'bw:'
• bwl:local - for a manually edit profile Intention is to show a Message to anyone using the url that the profile is not available
• http://example.com/profile.brf - for an external profile This is for a future extension: Allowing the user to add custom profiles like they can add custom layers

Is there any interest in this approach?

Code wise I've started with creating a new class (ProfileData) to have more centralized state for all this profile related data. My Intention is to move more of the current processing to this class so the UI-Elements can focus more on the UI part. Hopefully this would allow me to add some unit-tests for this stuff. Of course this will require a lot of refactoring and likely new bugs. Also it will take quite some time.

[tbsmark86]

As I understand, this would be a pure client-side solution that still relies on modifying and uploading a custom profile? Yes.

However, the server now provides a way (according to https://github.com/nrenner/brouter-web/issues/666) to Well that reads like this was not really intended by the Server? I'am not aware of any api doc for the server?

abrensch and I agreed not to automatically load and display content from arbitrary external URLs. Yes. My Idea was to first ask the user. fgcvfg Overall I read that as a 'no' to my question?

Or this profile:xyz is the 'official' way for the backend and just drop the profile-is-a-nested-url part?

[tbsmark86]

So if you're still interested Probably. Also feels more complex moving around multiple values instead of one opaque string I have think about that. But don't expect it soon. Maybe I split this into some refactoring first for smaller merges and getting a better view.

Also I think once this split of ProfileData class is in place it should be more simple to add localStorage solution for saving you 'personal' custom profile more easly. In a way this external url stuff would still be there you just have to copy&paste it once. But let's not get ahead of ourself here.

General Question: The current code is lots of "callback hell". Is this simply because it's rather old or are there any reasons to avoid more modern Promise or async/await ?

P.s. Sry about not being aware of the server. I don't want to dive into yet another code base.

[nrenner]

Also feels more complex moving around multiple values instead of one opaque string I have think about that.

But that's only when converting to/from URL, internally it would be a single object with key/value properties?

I don't like encoded "blobs" and would prefer to keep the URL unencoded and readable whenever possible. An alternative to multiple profile:*-prefixed URL parameters could be a single parameter with the key=value pairs separated e.g. by semicolon (;) instead of the parameter seperator (&), like we do e.g. in the lonlats parameter. The URL structure should be the same with that sent to the server, so this would need to be discussed in a server issue.

Also I think once this split of ProfileData class is in place it should be more simple to add localStorage solution for saving you 'personal' custom profile more easly. In a way this external url stuff would still be there you just have to copy&paste it once.

For me, using localStorage to remember a profile is less a technical but more a conceptional issue, how it fits with permanent/shared profiles on the server, or if localStorage is even needed once you can permanently store profiles on the server.

General Question: The current code is lots of "callback hell". Is this simply because it's rather old or are there any reasons to avoid more modern Promise or async/await ?

Using callbacks is not automatically "hell". In my understanding that term refers specifically to multiple nested callbacks, which I don't think we have that many. Originally I intended to still support older browsers and Babel was only introduced very late in the project. Now we can use modern JS features for new stuff and also gradually refactor what is being worked on (but please in a separate commit).