feat(Preview): add startRoute prop to override Provider default

[SSHari]

What kind of change does this pull request introduce?

I'm trying to render two Preview components that point to different pages (e.g. /about and /careers). This PR includes some rough changes and a Storybook story to better explain my intentions.

The core change is to add a startRoute prop to the Preview component that overrides the startRoute option that's passed to the Provider. When createClient is called in the useClient hook, the override value is used instead.

This idea could probably be extended for other things that may need an override, but for now, I explicitly exposed the startRoute functionality.

This may be an unnecessary change.

Based on the Preview Component documentation:

There's nothing stopping you from rendering multiple previews in the same Provider. They will all be connected to the same state source, but they can for example point to different pages of the same application.

If there's already a way to do this, could someone on the core Sandpack team point me in the correct direction?

Thanks!

What is the current behavior?

All Preview components start on the route defined by the startRoute option passed to the top-level Provider.

What is the new behavior?

A new startRoute prop has been added to the Preview component that lets you override the top-level Provider option.

What steps did you take to test this? This is required before we can merge, make sure to test the flow you've updated.

I created a Storybook story MultipleRoutePreviews that uses React Router. It defines two routes and renders two Preview components that point to the different routes. When the story loads up, each Preview component starts on the correct route now.

Checklist

• Documentation;
• Storybook (if applicable);
• Tests;
• Ready to be merged;

This PR is still very rough. There may be better ways to accomplish what I'm trying to do and any proposed change would still require an update to the documentation.

[vercel]

@SSHari is attempting to deploy a commit to the CodeSandbox Team on Vercel.

A member of the Team first needs to authorize it.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit b5db453:

Sandbox	Source
Sandpack	Configuration
sandpack-run-stale-value	Configuration

[danilowoz]

Hey, @SSHari. Thanks for opening this issue. What do you think about this approach here? #873 It seems simpler, and it doesn't overcomplicate the client creation.

But, being honest, your approach is more agnostic than the one I tried. I didn't like that I needed to add custom logic on each client to make it work. Let's give it a think.

[SSHari]

@danilowoz I think the approach you're suggesting is reasonable. While you have custom logic in each place, the changes are colocated with the general iframe logic for each client. It's probably easier to understand what's happening in your version for other people who are reading the code.

As you said, you also don't overcomplicate the client creation.

I think the only benefit of the approach I outlined is that it leaves the door open in case you need to override other settings in the client (e.g. maybe the logLevel needs to be different). I'm not sure if this will ever be necessary, but maybe other components will need something similar where we render multiple versions of the component with different options.

That said, if we do end up needing that kind of functionality, we can always revisit the approach above or come up with a better way to override values.

Ultimately a big concern for me is the user experience. I think both approaches are similar in terms of how you use the feature (i.e. add a startRoute prop to the Preview component). Given that's the case, I'd defer to your judgment in terms of how to best handle things from a maintenance and code clarity perspective.

[danilowoz]

I feel more comfortable with this solution now. Let's give it a try.

I fixed a couple of issues where different clients were consuming messages from each other, leading to unsync start route and console from the wrong client.

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
sandpack-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 5, 2023 8:13pm

[SSHari]

I feel more comfortable with this solution now. Let's give it a try.

I fixed a couple of issues where different clients were consuming messages from each other, leading to unsync start route and console from the wrong client.

Awesome! Thanks for getting those other issues resolved!