-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project: Modal workflow selection #1976
Conversation
7d45884
to
0f2241a
Compare
Still to do: new tests and stories. Maybe abstract some of the repeated code into new components. |
0704f21
to
c1aa0e7
Compare
The tutorial load observes and reacts to the workflow loading, so I think its store could be modified to instead observe and react to the subject load? |
Thanks! I think that would definitely fix this. The Classify page could also hold off on passing initial props to the classifier until |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this works! Grant mentioned it in Slack but reiterating here that the close buttons do still need to be removed. Everything else looks great!
Thanks for reminding me about the Close buttons (#1981.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR Review
Package: lib-classifier
This PR update shows the Workflow Selection modal on the /classify
path, when a project has multiple active Workflows. Also, this update shows the Subject Selection modal on the /classify/workflow/1234
path, when a Workflow has multiple active Subjects.
Unfortunately, I am encountering major issues while testing this PR - @eatyourgreens was this branch recently rebased to reflect changes made in #1963 ? I'm having issues while testing this.
Major Issue: "No Workflow ID" error"
Issue: whenever I try to go to the /classify
page of a Project with multiple active workflows (note: no default workflow), I will see the modal for 2 seconds, before the website crashes with the error ReferenceError: No workflow ID available
Testing setup:
- Any project with multiple active workflows, on localhost
- e.g.
http://localhost:3000/projects/msalmon/hms-nhs-the-nautical-health-service/classify?env=production
with 2 active workflows - note: I used
http://localhost:3000/projects/darkeshard/transformers/classify
with 2 active workflows. but please note that this project setup will be changing rapidly as I review different PRs, so best test on your own projects.
- e.g.
- macOS 10 + Chrome 87
Testing steps:
- go to the
/classify
route of the selected test project - Expected: the Workflow Selection modal should show, and the Classifier should halt all operations until I select my workflow
- Actual: the Workflow Selection modal shows for a few seconds. Then, the app crashes with the on-screen error - "Unhandled Runtime Error - Reference Error: No Workflow ID Available"
Analysis:
- From a brief debug of the code, it seems that while the classifier correctly identifies when to serve the Workflow Selection modal, the "try to fetch a workflow" logic is STILL going on, and it's trying to fetch Workflow "undefined".
- The "trying to fetch workflow undefined" action might explain why there's a few second delay between seeing modal and the app crashing.
Status
Issues detected, so I'm marking this review as a CR for the time being...
...BUT after digging into this further, I realise that the issue might be separate from this PR. After all, this PR adds a new Workflow Selection component (which seems to work great, even though my full testing capability is limited due to the issue) while the issue seems to stem from a workflow selection logic.
Hence, the question: was this PR rebased after 1963? I was looking at my tests from 1963 - specifically Scenario 4 - and I realise that the "No Workflow ID" error was encountered there.
Scenario 4: project has multiple active workflows, none of which is the default
- the "Classification" link in the header leads to: /projects/darkeshard/transformers/classify (This is sensible)
- navigating directly to the /classify route results in: ERROR, No Workflow ID available (Which IS expected 👍 )
So, thoughts: I think this PR (i.e. add new component) works fine in theory (code looks good), but I can't approve it until I've fully tested it, and that requires a fix to the workflow selection logic, which should bea separate PR.
Footnote: I'm now reviewing 1966 after 1976. I'm not sure if getting 1966 merged first will address the "No Workflow ID" error described in the PR Review, since - at the time of writing - 1966 has conflicts that need resolving. |
be7f6f4
to
2fdf9b8
Compare
686cddb
to
b6143e3
Compare
@shaunanoordin #1966 is the 'quick fix' to get workflow selection onto the Classify page so that we know we can use it in the Engaging Crowds beta. This PR is the more considered approach, using the final design and an interstitial popup, but I kept it seperate just in case it turned out that the classifier breaks when you render it before workflow selection is complete. I think definitely review #1966 first, then have a look at this PR. So #1966 is essential for the beta test. This is nice-to-have, if we can get it working in time. |
Some EDIT: totally worked! |
b6143e3
to
a04f6fe
Compare
Re. the workflow ID error, we have a design for a placeholder classifier that should show while we’re choosing a workflow, subject set etc. I’ll open an issue for that. |
That error you're seeing is being thrown by front-end-monorepo/packages/lib-classifier/src/components/Classifier/Classifier.js Line 68 in 9300aad
|
ede735e
to
8bbb34e
Compare
@shaunanoordin I've fixed the workflow ID errors. This PR is now a must-have for the Engaging Crowds beta test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM, no blocking comments. Nice separation of components, changes to Classifier.js
straightforward. Tests and stories are very helpful.
I see some SubjectSetCard propType warnings (expected ___ received undefined
).
Confirming as already noted that /classify/workflow
initial load had tutorial modal on top of subject selection modal. Not sure if there's a related issue/PR, but not blocking.
In addition to production project noted in comments, tested from project home and /classify
on staging projects projects/nora-dot-test/planet-finders-beta
and projects/wgranger-test/anti-slavery-testing
, without issues/warnings specific to this PR.
packages/app-project/src/shared/components/SubjectSetPicker/SubjectSetPicker.js
Outdated
Show resolved
Hide resolved
...-project/src/screens/ProjectHomePage/components/Hero/components/WorkflowMenu/WorkflowMenu.js
Outdated
Show resolved
Hide resolved
Thanks for the review @mcbouslog. I'll have a look at fixing the tutorial on this branch but it might need its own PR. |
Check for a subject set ID if the selected workflow is grouped. If there's no subject set ID, showing the workflow selector with the subject set picker active.
Move workflow selection state into the workflow selector. Add an onSelect handler to the workflow select buttons.
Wrap the workflow selector in a modal on the classify page. Force the modal to be active until a workflow is selected.
Extract workflow selection state from the workflow selector, so that we can have different behaviour in the Hero component or the project Classify page. Consumers are now expected to provide an onSelect handler, which reacts to workflow selection changes.
Remove the Modal component from the subject set picker. Consumers can now choose how they display it. The Hero component wraps the picker in a new modal. The Classify page wraps the picker in the same modal as the workflow selector.
Move all the shared code for the home page workflow menu into a WorkflowMenu component. Add stories and tests.
Move the subject set picker to @shared/components/SubjectSetPicker.
Add a back button to the subject set picker, and an onClose callback which is called when the button is clicked.
Allow workflow ID and subject set ID to be set after the classifier has mounted.
8bbb34e
to
de1e93a
Compare
Changes have been addressed now.
A continuation of #1966. This rewrites the workflow selector to allow us to have different behaviour on the project home page or on the project classify page. On the classify page, we'd like workflow selection to interrupt you with a modal dialog that forces you to choose a workflow, and optional subject set, before continuing to classify.
InVision prototype.
Entering a project via the general Classify URL should prompt to choose a workflow:
http://localhost:3000/projects/msalmon/hms-nhs-the-nautical-health-service/classify?env=production
Entering a project via the URL of a workflow that requires a subject set should prompt for subject set selection:
http://localhost:3000/projects/msalmon/hms-nhs-the-nautical-health-service/classify/workflow/16807?env=production
Neither of those pages should open the workflow tutorial in a popup.
Package:
app-project
Review Checklist
General
Components
Apps
yarn panic && yarn bootstrap
ordocker-compose up --build
and app works as expected?Publishing
Post-merging