Skip to content
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

fix/dyad census and tie strength census #73

Merged
merged 5 commits into from
Feb 2, 2024
Merged

Conversation

buckhalt
Copy link
Member

@buckhalt buckhalt commented Feb 1, 2024

When there are no steps and multiple prompts on Dyad Census and Tie Strength Census interfaces, navigation back/forward should ignore multiple prompts and force next/prev stage.

With the refactor of navigation and implementation of useNavigationHelpers, this functionality was removed. The default navigation prompted navigation to the next/prev prompt instead. This caused an issue where next/prev navigation buttons appeared to need to be clicked multiple times to advance past the introduction, once for each prompt.

This PR fixes navigation for dyad census and tie strength census by forcing navigation to next/prev stage if there are no steps. This is implemented using an optional options prop in the moveBackward and moveForward methods in useNavigationHelpers.

Runtime errors on these interfaces are also fixed here.

Copy link

vercel bot commented Feb 1, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
fresco ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 1, 2024 10:56pm

if there are no steps, dyad and tie strength should automatically allow progress to next stage even if there are additional prompts (because those will also not have steps). this functionality was removed with implementation of useNavigationHelpers. reimplemented using an optional prop options in moveForward and moveBackward
Copy link
Member

@jthrilly jthrilly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really well done for figuring this out.

I don't love the idea of polluting the function signature for moveForward/moveBackward with options, but I see why it has to be done.

There are two things to think about:

  1. Is options and then forceStageChange right right structure and naming convention? Here I would ask if we are likely to add more "options" in the future (my thinking is probably not), and then if not could I make it a single function parameter perhaps just simply called force. We would get some IDE autocomplete on then when using it, which would work nicely.
  2. The other approach, which could actually be combined with the approach above, would be to have the hook export alternative versions of the navigation methods that don't perform the prompt check. You could call these forceMoveBackward and forceMoveForward. They could be implemented internally using a variable as in (1), but this implementation detail could be hidden from the consumer. The obvious downside to this is more verbiosity.

Just posting these considerations as stuff to think about if you didn't already! Going to merge this in as-is.

@jthrilly jthrilly merged commit b30f1c9 into main Feb 2, 2024
5 checks passed
@jthrilly jthrilly deleted the fix/dyad-tie-strength branch March 28, 2024 09:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants