Fix wrong model after login (#213) #354
Conversation
🦋 Changeset detectedLatest commit: 990ece9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
hassoncs
force-pushed
the
fix-wrong-model-after-login-213
branch
from
4d22dac to
8be91f3
Compare
hassoncs
changed the title
Previously we were spreading the entire `prevCachedState.apiConfiguration` object when the keys changed, which would wipe out unsaved changes the user might have made to things like `prevCachedState.apiConfiguration.kiloModel`. Now we only set the keys that might be set via callback and don't trigger a save explicitly. The user will need to click 'save' in order to exit the SettingView like normal (same as changing any other setting). - update state with specific tokens/keys to avoid overwriting unsaved changes - simplify useEffect dependencies by using direct variables **Dev thoughts** This does make me think.. should "login" keys / tokens be a "setting"? seems like it should be in the Settings view UI, but possibly separate from the other settings state of the api. I feel like it's not intuitive to have to click a "save" button once you login to something for it to remain saved. **Test plan**: Verified that logging in / out no longer overwrites other non-saved changes in the Settings. Now users will have to click save for any changes they make, including login state. (This should be ok since we have that confirmation dialog if they don't.) **Closes** #123
hassoncs
force-pushed
the
fix-wrong-model-after-login-213
branch
from
8be91f3 to
990ece9
Compare
There was a problem hiding this comment.
Looks good to me, unsure about the .changeset file if that should be included,
@kevinvandijk should this PR have a .changeset file?
I agree. This is a bit of a weird flow but we accepted it for now because usually people will only log in on the welcome flow and logging out here and logging back in is not a common use case. Once we start on customizing it to be our own settingsview we should work on improving that. Eventually we like to add token support as well in #240 but this also requires backend changes. |
Previously we were spreading the entire
prevCachedState.apiConfigurationobject when the keys changed, which would wipe out unsaved changes the user might have made to things likeprevCachedState.apiConfiguration.kiloModel. Now we only set the keys that might be set via callback and don't trigger a save explicitly. The user will need to click 'save' in order to exit the SettingView like normal (same as changing any other setting).Dev thoughts
This does make me think.. should "login" keys / tokens be a "setting"? seems like it should be in the Settings view UI, but possibly separate from the other settings state of the api. I feel like it's not intuitive to have to click a "save" button once you login to something for it to remain saved.
Test plan: Verified that logging in / out no longer overwrites other non-saved changes in the Settings. Now users will have to click save for any changes they make, including login state. (This should be ok since we have that confirmation dialog if they don't.)