feat: OPTIC-1553: Add URL-based region visibility, hiding all but the specified region on load #6880
Conversation
👷 Deploy request for label-studio-docs-new-theme pending review.Visit the deploys page to approve it
|
👷 Deploy request for heartex-docs pending review.Visit the deploys page to approve it
|
makseq
changed the title
|
@ddishi could you please rename your feature flag to this one: |
|
@ddishi Would you be able to add some tests for this change? Test case(s) for this can be added here: |
|
Thanks a bunch @ddishi 🙏 |
| @@ -214,22 +229,39 @@ export const AppStore = types | |||
|
|
|||
| if (annotationID !== undefined) { | |||
| self.annotationStore.setSelected(annotationID); | |||
| } else { | |||
| self.taskStore.setSelected(taskID); | |||
| } | |||
There was a problem hiding this comment.
Can you explain why the else case was removed?
There was a problem hiding this comment.
Because we need to load the task even if an annotationID is provided for the FF to work properly. We need to be able to choose both annotationID and taskID.
Also we always have taskID defined since we return otherwise.
There was a problem hiding this comment.
But in the case of a defined annotationID we already have the task loaded and selected. We don't need to reload the task to switch annotations, that would incur an overhead which seems unnecessary.
There was a problem hiding this comment.
@bmartel I believe that this is specifically not the case with the URL argument. Maybe there is some kind of race condition or something. We'd appreciate your input
There was a problem hiding this comment.
I'll have to look closer, but the reason I flagged this is because there are two cases that were originally handled in this function.
- Switching tasks
- Switching annotations within a task
The removal of the else case means that in the case we are only switching an annotation, we now would be always loading the task from the API even though it has not changed. There seems like there should be a way we can position this to avoid introducing an unnecessary API call for a task we already have.
@hlomzik does this make sense?
There was a problem hiding this comment.
We checked it again and the feature seems to be working with the else block after all... I'll revert it.
Thanks for pointing that up 🙏🏼
ddishi
force-pushed
the
fb/focus-on-region-via-url
branch
from
a5df055 to
e458602
Compare
PR fulfills these requirements
[fix|feat|ci|chore|doc]: TICKET-ID: Short description of change madeex.fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errorsChange has impacts in these area(s)
(check all that apply)
Describe the reason for change
Couldn't provide a URL to a specific region while maintaining context.
What does this fix?
(if this is a bug fix)
What is the new behavior?
The ability to read URL parameters in order open the task\annotation with only the specified region presented while all other regions are hidden.
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
fflag_feat_front_optic_1553_url_based_region_visibility_shortDoes this PR introduce a breaking change?
(check only one)
What level of testing was included in the change?
(check all that apply)
Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)