Support reading URL query params

[calebjacob]

We need to provide some way of reading the current URL's query parameters inside of any component. This could also impact how we allow component authors to programmatically change the URL in the future.

[calebjacob]

Michael Peter
🤒 18 minutes ago
I am a bit torn on props URL implementation, do we just tie into the strings from query params or should we make props a base64 encoded JS object in the URL

Michael Peter
🤒 17 minutes ago
maybe we start with strings and then extend to object later, I could see use cases for both. I certainly manipulate BOS urls directly

Caleb Jacob
17 minutes ago
I suppose a third solution would be to create a new URL plugin (similar to wallet selector plugin) that they could import to read the current URL params. This would then lend itself to allowing them to push/modify the URL programmatically.

Michael Peter
🤒 16 minutes ago
yeah possibly, although then a component would have to built specifically for being a root component or a child component

Michael Peter
🤒 16 minutes ago
I think abstracting that through props is good, although your other use case sounds like a plugin we will need

Caleb Jacob
15 minutes ago
I might not track with that first comment (could be my congestion, haha)

Michael Peter
🤒 14 minutes ago
if you build a component to read URL params, then I can’t embed it in my component and pass it those same configuration values as props

Michael Peter
🤒 14 minutes ago
its better to just get values from “above” and not be aware if that is another component or the gateway URL

Caleb Jacob
13 minutes ago
Ah, that's a fair point. Though the developer of that component would still need to add the correct prop types.

Caleb Jacob
11 minutes ago
I guess what I'm imagining would line up closer with typical React development. You'd import next/router to read and update the URL. You wouldn't expect URL props to be passed through magically.
As the developer of the component, you could easily decide to allow a prop to be passed in to override a value. But by default, you'd look for the URL value.

Michael Peter
🤒 9 minutes ago
I see what you’re saying, I think this is one of the main places where we diverge from React behavior due to the added composability of BOS and common use case of components that were written to be root then being embedded in other experiences

Michael Peter
🤒 9 minutes ago
we’re forcing components to be more agnostic about their usage scenarios

Caleb Jacob
6 minutes ago
That's a fair point. We might run into challenges with how to handle prop types.

[mpeterdev]

from roadmapping session:

Seems like we would be better served by only allowing props as a base64 encoded JSON payload and requiring that gateways offer both a way for end users to modify the current props and also an engine plugin/lib for easily generating links to components with props set

Potentially tied into the Link component

merits some discussion on how strongly we push for components exporting a typed props object so that the gateway and other components can reliably tie into them

[calebjacob]

After discussing with @mpeterdev, we decided to stick with a simpler solution for our first pass. Essentially, it'll function very similarly to how the current VM handles query params and passes them into the root component.

We'll support string based query parameters with the format we're all familiar with. EG: /calebjacob.near/MyApp?tab=Featured

The gateway (Next JS app) will pass all query params to the useWebEngine() hook. The hook will then be responsible for injecting each of these query params as a prop to the root component.

For the example above, you'd write a RoC component like so:

type Props = {
  tab?: string;
}

function MyApp({ tab }: Props) {
  ...
}

The only catch here is that if you were passing a number-like or boolean-like value /calebjacob.near/MyApp?someNumber=23&someBoolean=true, it will still be a string (just like how URL query params typically behave):

type Props = {
  someNumber?: string; // Correct
  someNumber?: number; // Wrong
  someBoolean?: string; // Correct
  someBoolean?: boolean; // Wrong
}

We could potentially support an option for automatically parsing these values based on export prop types, but that's out of scope for now.

[calebjacob]

Ended up being blocked due to pnpm dev no working for me - so I created a fix here: #426