Add user preferences support to iD editor via server-side rendering

[Deeptanshu-sankhwar]

Add User Preferences Support to iD Editor

Summary

This PR implements server-side rendering of user preferences for the iD editor, making them accessible in the client-side JavaScript context.

Technical Changes

Server-side (app/views/site/id.html.erb):

• Added user preference collection logic that fetches all preferences for the current user
• Converts preferences from ActiveRecord objects to a hash structure ({key => value})
• Serializes preferences as JSON and includes them in the data attributes passed to the iD container

Client-side (app/assets/javascripts/id.js):

• Added preference parsing logic that extracts user preferences from the container's dataset
• Parses JSON-encoded preferences and makes them available globally via window.OSM.userPreferences
• Provides fallback to empty object for unauthenticated users or users without preferences

Implementation Details

• Follows existing pattern used for other iD editor data (token, locale, asset_map)
• User preferences are fetched via current_user.preferences.each_with_object({}) for efficient hash construction
• Data flow: Database → Ruby hash → JSON string → HTML data attribute → JavaScript object
• Preferences are only included when current_user exists (authenticated users)
• Client-side code gracefully handles missing or malformed preference data

Use Case

This enables the iD editor to access user-specific preferences (such as display settings, editor configurations, etc.) that were previously only available through separate API calls, improving performance and reducing client-server round trips during editor initialization.

Testing

• Verified with authenticated users having preferences
• Verified with authenticated users having no preferences
• Verified with unauthenticated users
• Confirmed preferences are accessible via window.OSM.userPreferences in browser console

[tyrasd]

This could probably better handled in method of the idContext object, instead of as a new global variable.

[Deeptanshu-sankhwar]

I have now embedded a function in the idContext object to store and then consume user preferences

[tyrasd]

enables the iD editor to access user-specific preferences

Just for clarity: this is not quite yet implemented in the current version of iD, but @Deeptanshu-sankhwar is working on it right now. This means that the code will only be needed to be merged once we're deploying the next release of iD which comes with that code (that PR than probably be replacing this one). But we thought it might be nice to put this out anyway for you to give it a look already.

[tyrasd]

it's probably not required to check for current_user as this page requires to be logged in to load, and the variable is already used on line 14.

[Deeptanshu-sankhwar]

Thanks @tyrasd , I have removed the redundant check now

[mmd-osm]

Do we really need all user preferences for iD? This could be a fair amount of data, such as lots of overpass turbo queries. How about only adding preferences that are relevant for iD?

[pnorman]

This enables the iD editor to access user-specific preferences (such as display settings, editor configurations, etc.) that were previously only available through separate API calls, improving performance and reducing client-server round trips during editor initialization.

It seems that all of these would come from one call of /api/0.6/user/preferences. As it's only one call, it doesn't seem like it would have a large performance impact. Or is the concern that a user might have other large preferences (e.g. overpass turbo queries) and the /preferences result will be too large?