Wp-calypso: Gutenboarding: Move create-my-site button to style preview

Created on 18 Mar 2020  路  5Comments  路  Source: Automattic/wp-calypso

We need to move the Create my site button from the header to the style preview section.

Current:

Screenshot 2020-03-16 at 2 16 00 PM

Figma:

Screenshot 2020-03-16 at 2 16 14 PM

See originating thread: https://github.com/Automattic/wp-calypso/issues/40138#issuecomment-599508709

[Goal] New Onboarding [Type] Task

Most helpful comment

Follow-up to my call with @chriskmnds yesterday -- we were discussing using a @wordpress/data store to control visibility of the signup and login forms. However, I had totally forgotten about React Context, which would be a better fit for UI related state such as this (thanks @sirreal and @razvanpapadopol!)

Maybe we'll be able to tackle this problem even without resorting to useContext, by 'simply' extracting all the required logic. In any case, we should start by getting a clear picture of all the flows that are defined in the header, since -- because of component state and useEffect -- it's not obvious at first glance.

Here's a rough sketch:

  1. User needs to create a site, either by clicking 'Create my site', or by purchasing a domain.
  2. If the user isn't logged in, we prompt them to sign up (handleSignup)
  3. In the signup modal, there's an alternative option to log in with an exisiting user account (handleLogin)
  4. Once they are logged in, we create the site (handleCreateSite, triggered from a useEffect hook)
  5. If the user ended up here by purchasing a domain, we put that domain product in the cart.
  6. We clear all onboarding data and redirect to the newly created site's editor.

Component state (that tracks visibility of modals) and methods that set various combinations of those visibility states, in addition to listeners (useEffect) seem like a counter-intuitive representation of such a flow. Note that e.g. the two last steps (putting a domain product into the cart, clearing data and redirecting) happen through a useEffect event listener that evaluates if isDomainFlow state has been set earlier. This is seriously hard to read, maintain, and extend.

@sirreal has suggested looking into a Finite State Machine such as XState to allow us keeping better track of this flow. (They also have docs on Usage with React.) I haven't given this a very in-depth look, but I think it's worth a try, given that the flow we're dealing with is pretty complex already, and the tools that React/Redux/@wordpress/data supply us with don't seem adequate.

All 5 comments

Follow-up to my call with @chriskmnds yesterday -- we were discussing using a @wordpress/data store to control visibility of the signup and login forms. However, I had totally forgotten about React Context, which would be a better fit for UI related state such as this (thanks @sirreal and @razvanpapadopol!)

Maybe we'll be able to tackle this problem even without resorting to useContext, by 'simply' extracting all the required logic. In any case, we should start by getting a clear picture of all the flows that are defined in the header, since -- because of component state and useEffect -- it's not obvious at first glance.

Here's a rough sketch:

  1. User needs to create a site, either by clicking 'Create my site', or by purchasing a domain.
  2. If the user isn't logged in, we prompt them to sign up (handleSignup)
  3. In the signup modal, there's an alternative option to log in with an exisiting user account (handleLogin)
  4. Once they are logged in, we create the site (handleCreateSite, triggered from a useEffect hook)
  5. If the user ended up here by purchasing a domain, we put that domain product in the cart.
  6. We clear all onboarding data and redirect to the newly created site's editor.

Component state (that tracks visibility of modals) and methods that set various combinations of those visibility states, in addition to listeners (useEffect) seem like a counter-intuitive representation of such a flow. Note that e.g. the two last steps (putting a domain product into the cart, clearing data and redirecting) happen through a useEffect event listener that evaluates if isDomainFlow state has been set earlier. This is seriously hard to read, maintain, and extend.

@sirreal has suggested looking into a Finite State Machine such as XState to allow us keeping better track of this flow. (They also have docs on Usage with React.) I haven't given this a very in-depth look, but I think it's worth a try, given that the flow we're dealing with is pretty complex already, and the tools that React/Redux/@wordpress/data supply us with don't seem adequate.

I had another look. The problem I currently see with XState is that a lot of our criteria is coming from Redux (e.g. currentUser, newUser). I think that if we were to use XState, we'd end up duplicating some of that information to send it to XState. This seems suboptimal (though it's entirely possible that I'm missing something, as I'm still not really familiar with XState).

My current thinking is that I'd like to remove a few of those useEffect listeners and make things more explicit by e.g. passing an onSignup prop to the signup form that'll allow us to create a site if the user has successfully signed up. I hope to be able to do something similar with the domain purchase flow. I _think_ that this will allow for a somewhat more readable flow, and for better containing the relevant logic in one place, so that we'll be able to move the 'Create my site' button elswhere.

WIP at #40552.

This is done.

(Closed by #40656.)

Was this page helpful?
0 / 5 - 0 ratings