Avoid adding duplicates to the list of welcome projects, and ... #2812
Conversation
…nd clean up existing duplicates
ghost
assigned 
|
Reviewing |
| }; | ||
| _prefs = PreferencesManager.getPreferenceStorage(PREFERENCES_CLIENT_ID, defaults); | ||
|
|
||
| if (!_prefs.getValue("welcomeProjectsFixed")) { |
There was a problem hiding this comment.
I understand the intent of this code, but I'm a bit worried about adding backward compatibility code like this so early in development. Over time, this type of code becomes difficult to manage and maintain.
Personally, I would be fine with just removing this block. If you feel strongly about keeping it, I think it would be best to file a code cleanup bug to remove this code after a sprint or two (this is making the assumption that most current Brackets users are updating every sprint or two, and would have already had there old prefs cleaned up).
Thoughts?
There was a problem hiding this comment.
Removing it after a couple sprints seems reasonable to me, fwiw. I do think we should have it in there temporarily, though -- I bet lots of people don't clear prefs routinely and will hit the issue I saw given enough time (and I think the end result is that we just stop remembering pref changes without warning).
There was a problem hiding this comment.
Yes, I think we should leave it in for a few sprints.
|
Initial review complete. |
Avoid adding duplicates to the list of welcome projects, and ...
...clean up existing duplicates
Fixes #2809.
In the part of the code where we were explicitly writing out a new set of welcome folders, we were properly detecting duplicates. But there was another bit of code in
isWelcomeProjectPath()that was accessing the welcome folder array and pushing the current welcome path onto it temporarily, just for the purposes of including it in the list so that theindexOf()on the next line would also check it. This seemed safe (although not really all that smart anyway) since we didn't callsetValue()again. However, it turns out that array/object values returned from thePreferenceStorageare actually live objects cached in the preference structure, so if you modify them, the new values will eventually get saved out even without an explicitsetValue(). Not sure if this is a bug or a feature.In any case, the fix is simple (don't push the extra value on, just check it separately). I also added a one-time check to clean up existing duplicates due to the original bug--seems important since people might have tons of garbage in their prefs file.