feat(ui): Do not load Global Selection values from local storage in Issue Details #13689
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
billyvg
force-pushed
the
feat/ui/dont-load-global-selection-local-storage-on-issue-details
branch
from
7ec0f40 to
2273448
Compare
…ssue Details This is for the case where an Issue is accessed from a direct URL. Previously it would load the last accessed project/env from local storage. This is not desired behavior when accessing an Issue directly. This will look for a route to Issue details and avoid loading the store. However we also want to initialize the store if we leave the issue details page. Otherwise (this is exacerbated in the single project case), you could have last accessed project `Foo`, open url to issue in `Bar`, and then navigating from Issue to Issues list could result in a project that is neither `Foo` nor `Bar`. Fixes SEN-709 Fixes SEN-658
billyvg
force-pushed
the
feat/ui/dont-load-global-selection-local-storage-on-issue-details
branch
from
2273448 to
89c3e17
Compare
lynnagara
reviewed
Jun 18, 2019
src/sentry/static/sentry/app/components/organizations/globalSelectionHeader/index.jsx
Outdated
Show resolved
Hide resolved
lynnagara
reviewed
Jun 18, 2019
src/sentry/static/sentry/app/components/organizations/globalSelectionHeader/index.jsx
Show resolved
Hide resolved
billyvg
deleted the
feat/ui/dont-load-global-selection-local-storage-on-issue-details
branch
billyvg
added a commit
that referenced
this pull request
Apr 22, 2020
This basically re-implements #13689 in a more simple way. This is possible due to other changes that we have done to issue details (#13875, #14731). This also (semi) fixes an issue with loading Issue Details with an environment in the URL. Previously, it would fetch details API serially: 1) without env and 2) with env. There would be a slight flicker between loading -> finished req #1 -> loading -> finished req #2. Now this seems to fire both at near the same time and cancels the initial request almost immediately. This is still not ideal but is an interim-fix as the ideal solution is a bit more involved, but will be on its way.
billyvg
added a commit
that referenced
this pull request
Apr 23, 2020
This basically re-implements #13689 in a more simple way. This is possible due to other changes that we have done to issue details (#13875, #14731). This also (semi) fixes an issue with loading Issue Details with an environment in the URL. Previously, it would fetch details API serially: 1) without env and 2) with env. There would be a slight flicker between loading -> finished req #1 -> loading -> finished req #2. Now this seems to fire both at near the same time and cancels the initial request almost immediately. This is still not ideal but is an interim-fix as the ideal solution is a bit more involved, but will be on its way.
billyvg
added a commit
that referenced
this pull request
Apr 26, 2020
This basically re-implements #13689 in a more simple way. This is possible due to other changes that we have done to issue details (#13875, #14731). This also (semi) fixes an issue with loading Issue Details with an environment in the URL. Previously, it would fetch details API serially: 1) without env and 2) with env. There would be a slight flicker between loading -> finished req #1 -> loading -> finished req #2. Now this seems to fire both at near the same time and cancels the initial request almost immediately. This is still not ideal but is an interim-fix as the ideal solution is a bit more involved, but will be on its way.
billyvg
added a commit
that referenced
this pull request
Apr 27, 2020
This basically re-implements #13689 in a more simple way. This is possible due to other changes that we have done to issue details (#13875, #14731). This also (semi) fixes an issue with loading Issue Details with an environment in the URL. Previously, it would fetch details API serially: 1) without env and 2) with env. There would be a slight flicker between loading -> finished req #1 -> loading -> finished req #2. Now this seems to fire both at near the same time and cancels the initial request almost immediately. This is still not ideal but is an interim-fix as the ideal solution is a bit more involved, but will be on its way. The tests introduced in #18452 should cover the changes in this PR.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is for the case where an Issue is accessed from a direct URL.
Previously it would load the last accessed project/env from local storage.
This is not desired behavior when accessing an Issue directly. This will
look for a route to Issue details and avoid loading the store.
However we also want to initialize the store if we leave the issue details
page. Otherwise (this is exacerbated in the single project case), you could
have last accessed project
Foo, open url to issue inBar, and thennavigating from Issue to Issues list could result in a project that is
neither
FoonorBar.Fixes SEN-709
Fixes SEN-658