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

💥 !Define searchParamIntegration! 💥 #291

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

devinrhode2
Copy link

@devinrhode2 devinrhode2 commented Aug 23, 2023

Context: I am building a SolidStart app which will be embedded into other non-Solid-based apps by simply injecting the html+scripts of the SolidStart app at runtime. Once an initial URL is constructed for the SolidStart app, a component similar to this is used to inject the scripts + html. The html+scripts come from my SSR'd SolidStart app.

Context2: To make this SolidStart "widget" or "micro-frontend" truly isomorphic, it needs to add some state into the url. (Cookies could be another option). This of course allows the server to SSR the right page.

This PR creates a new way for Solid apps to handle routing, where the pathname and search params for a solid app are encoded into a single search param. This allows Solid apps to be embedded into larger apps without adversely affecting their url.

Host url: /hPath1/hPath2?hParam1=hParam1Value#hHash
Solid app's url: const solidUrl = '/sPath1/sPath2?sParam1=sParam1Value#sHash'

Host app's url, with Solid app embedded inside it:

  1. Set query param: searchParamIntegration('CARNIATOMON')
  2. Encode it: /hPath1/hPath2?hParam1=hParam1Value&CARNIATOMON=${encodeURIComponent(solidUrl)}#hHash
  3. Fully encoded: /hPath1/hPath2?hParam1=hParam1Value&CARNIATOMON=%2FsPath1%2FsPath2%3FsParam1%3DsParam1Value%23sHash#hHash

// Because the above `pushState/replaceState` call should never change `window.location.hash`,
// this behavior from `pathIntegration` doesn't make sense in the context of `searchParamIntegration`:
// scrollToHash(window.location.hash.slice(1), scroll);
// Perhaps when a widget loads, it should run the `el.scrollIntoView` function itself.
Copy link
Author

Choose a reason for hiding this comment

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

Although url hashes in the Solid widget url are not disallowed, I wasn't sure how the hash-scrolling behavior could be carried over into this new context. Let's say we have a Solid app we want to embed into another app. The scripts get injected. This "widget" is handling the entire screen between the header and footer. Therefore, it may have <h1> links inside the page. In this case, perhaps searchParamIntegration should get some new functionality. If a Solid.js-based micro-frontend can agree to a contract with the parent/host app that the parent/host app will not be using url hashes when the Solid.js-based micro-frontend is active, then searchParamIntegration could take in an extra parameter to indicate that url hashes should not be encoded into the search param, but instead independently added/removed to url. Given this contract and some new parameters passed to searchParamIntegration, searchParamIntegration could then mostly copy the scroll behavior of pathIntegration.

@devinrhode2 devinrhode2 marked this pull request as ready for review August 23, 2023 15:18
@devinrhode2
Copy link
Author

I guess I'm pioneering... "isomorphic micro-frontends"... 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant