-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Checklists: Redux state, declarative structure #26216
Conversation
From a code perspective, this stuff is a little over my head. Let me know how I might be able to test it out when it's ready. |
3a413a7
to
beb61d9
Compare
* This should be a simpler dispatched action. | ||
* Look at moving logic into middleware. | ||
*/ | ||
void launchTask( { |
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.
This should go somewhere else and we'd just dispatch an action…
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.
Yeah, I think ideally, I'd love to decouple the tour from the checklist even more -- i.e. really just pass in an onClick
handler function, and make the Task
block ignorant about GT specific stuff such as tourSlug
, tourUrl
, etc.
Follow-up material tho.
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.
(Oh, which might mean we would possibly ditch the Task
block and try to encapsulate that bound launchTask
function elsewhere...)
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.
Okay, scrolling down to the Task
component, I realize this is the major distinction between the component and the block. I think I'd still even go as far as to possibly remove the block altogether if we can find a different way of encapsulating the launchTour
function...
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.
Yes, I agree with you here @ockham. I think this PR is a good balance of introducing the new, more declarative checklist components, and the Task
block may well be a temporary measure.
My inclination is that this PR is in a sweet spot right now, it introduces the components and maintains a connected block that makes the state.checklist
-connected Tasks trivial to declare.
Finding the right place to handle tour start from the task (and whether that's implemented where/how it should be, or if it should be rethought entirely) can be part of a follow up.
What are your thoughts?
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.
Yep, sounds good! I think what seems the most arbitrary to me is that coupling of Guided Tours internals to the checklist. Agree that this PR is a good step towards decoupling that 👍
@@ -40,6 +38,7 @@ export class ChecklistHeader extends PureComponent { | |||
<ProgressBar compact total={ total } value={ completed } /> | |||
</div> | |||
<div className="checklist__header-secondary"> | |||
{ /* eslint-disable-next-line jsx-a11y/label-has-for */ } |
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.
nesting and id are required, I'm not sure why. This file is moved but otherwise unchanged. Ignore rule.
a7d4a2d
to
2f8355f
Compare
@fditrapani This is ready for some testing. I've added some instructions about where the Checklists can be found for testing and what should be expected (same behavior as staging/production). I'd appreciate any testing feedback you can provide, thanks! |
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 didn't do a full review of the code, but this is testing out perfectly for the usage in Store.
2f8355f
to
1292d25
Compare
buttonPrimary | ||
completedTitle="Yaks shaved." | ||
description="Make sure you shave the yaks so you can get on with your life." | ||
duration="10,000 minutes" |
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.
🤣
1292d25
to
f56f5cd
Compare
I've pinged a few folks for some manual testing as a checklist in the PR description. If folks will contribute some manual testing to a checklist in their domain, @Automattic/luna and @ockham should be able to handle code review. Thanks! |
Cherry-picked from: d3d9ba1
d1b2e6f
to
1bc0cd9
Compare
Adds Components from #26216 Uses components for WooCommerce Store checklist Uses components for ChecklistShow Removes blocks (discourage block usage)
Adds Components from #26216 Uses components for WooCommerce Store checklist Uses components for ChecklistShow Removes blocks (discourage block usage)
Closing in favor of #26618 and follow-up work. |
Adds Components from #26216 Uses components for WooCommerce Store checklist Uses components for ChecklistShow Removes blocks (discourage block usage)
* Add and use Checklist components, remove blocks Add components from #26216 Use components for WooCommerce Store checklist Use components for ChecklistShow Remove blocks Update devdocs accordingly * Separate state and structure in checklist banner
This PR continues separation of state and declarative structure work outlined in #26216. Inspired by suggestions from ockham, the Checklist is declared once in idiomatic React JSX, and can be rendered as a checklist of tasks or a banner (see `viewMode` prop). * `ChecklistShow`, responsible only for rendering the WordPress.com checklist, has been removed. * The array of task props in `onboardingChecklist` has been removed, and is now JSX in `WpcomChecklist`. * `ChecklistBanner` has been removed and replaced by `<WpcomChecklist viewMode="banner" />`. * `ChecklistMain` renders the `WpcomChecklist` and some surrounding UI. Clean up its usage of task status for calculating completion. * Remove the `mergeObjectIntoArrayById` util which is no longer needed and related tests
Implementing ideas from #26015
Supersedes #26030
Closes #25958
This strikes a middle-ground of keeping array-of-objects that can be iterated over to produce a full checklist or a banner.
It also provides the option of building completely declarative checklists, which we do with the store checklist.
The props produced by
connect
are fewer and less likely to change.Most importantly, we avoid merging declarative, structural information with state.
This will be helpful for future progress, such as #25935 and #25954
Todo:
mergeObjectIntoArrayById
)launchTask
somewhere better (Redux actions or middleware)This could be handled in a follow-up, everything works in this PR, this is additional cleanup.
Testing
Checklists may be used in 4 places. The functionality should remain unchanged for all of them:
Functionality:
Checklists in use to test:
/stats/day/SITE
) (@taggon / @fditrapani)/plans/my-plan/SITE
) (@Automattic/luna)/store/SITE
) (@timmyc)Drop the following in https://calypso.live/devdocs/playground?branch=update/checklist-separate-state-structure
cc: @ockham @fditrapani