User settings

User Settings

Editor Settings

We’ve added a number of editor-related changes recently, and I think it would be beneficial for users to be able to modify certain editor settings and it be persistent in the application. A super easy solution there would be to have them stored in local storage and loaded when the editor is loaded.

These could be in an object type editorSettings value on the user schema. This would allow for a more gentle-handed approach to its schema as new settings are added.

As some examples of things that we might want to include in the editor settings, we could include the following:

• enable/disable active line highlighting
• enable/disable code folding
• enable/disable line numbers?
• change tab size
• option to indent with tabs vs spaces
• enable/disable auto-closing html/curly brace tags
• enable/disable showing trailing spaces
• editor theme?

Any other options/ideas people have are welcome!

[calculuschild]

I think MongoDB Atlas places each Database on a separate physical server. We would need two collections in the same Database to make them share hardware.

However, with option 1 I don’t think there is any need to cross-reference between databases anyway. The user logs in at NaturalCrit and gets a JWT token from it. Then we just get the username from that token when it comes time to look up any preferences in the Homebrewery database. We never need to go back and update anything in the Naturalcrit side unless we are actually on the login page.

[calculuschild]

How do we want to handle users who do not have accounts? Do we want editor options to persist between browser sessions? (i.e., do we want to use LocalStorage as a fallback still?)

In any case, we do have two separate databases currently in use, and I think resolving the following is going to be the starting point for everything else here: We have 1) NaturalCrit (usernames and passwords for login) and 2) Homebrewery (brew documents).

The original intent of the two separate databases, was that “NaturalCrit” would be home to a suite of separate apps, with the NaturalCrit database holding a central log-in service for all apps, and then the Homebrewery for instance having its own database holding documents created via that app.

If we are going to be storing Homebrewery-specific user settings, we need to clear up in which database that belongs. I see a few approaches, and I think we need to settle on one before moving on:

1. Leave the Naturalcrit Database as is, and add a second collection to the Homebrewery database which simply stores username as an index, and then a list of their preferred settings specific to the Homebrewery. There is no need, I think, to store password hashes in this “preferences” collection if it is solely for looking up user preferences. The NaturalCrit Database is only ever accessed on login, and then does not need to be touched during use of the Homebrewery app.

2. Convert the Naturalcrit Database into a collection within the Homebrewery database, and delete the NaturalCrit database. User logins as well as preferences for the Homebrewery would be centralized in one location. However, this muddies the possibility of developing future apps under the NaturalCrit account system which would all end up sharing the database.

3. Leave the Homebrewery Database as is, and include all of the user preferences in the existing NaturalCrit Database. This also centralizes all user info in one location, but makes access a little trickier; we would need to set up Mongoose to simultaneously connect to both NaturalCrit and Homebrewery to pull data from both databases at once.

I may be missing something here, but personally option 1 seems the easiest and “best” way to do this. Yes, we would have two separate “user” collections, but they don’t need to hold anything in common other than the username as an id. This way future apps could also have their own user settings specific to that app without worry of one app’s settings treading over the other. I think this is also closer to @G-Ambatte 's original vision?

Once this is decided, I think we can select the main essential elements of the UserPreferences schema, perhaps limiting ourselves to “editorPrefs” for now, and implement that to resolve this issue. If that is successful, we can break out the other proposed features (user snippets, etc.) into their own issues to be worked on, since we will now have a framework to build on.