#sure which one
1 messages · Page 1 of 1 (latest)
if i understand what you're doing
then you just need to publish a react package to npm
Thanks for taking the time to let me pick your brain btw
Yeah, and ive done this for component libraries in the past with rollup but never with next
I built something very similar to what you're doing a few months ago
but it wasnt surveys
and i'm trying to retain the ISR aspect of the app so that it can be generated based off of the json object
theres a decision to make in this architecture
For example, this is all my survey app structure is:
src
pages
[survey-id]
[...question].tsx
Do you care if consumers of your widget can decompile it and view the code of the react components
which i think is pretty cool!
All the different components for questions can be rendered into that single page and based off the step-id in the json object it handles the order/sequence
If the answer to that is no, then you most likely do not need an iframe
well the components are actually in a component library that I built that is being imported as a package into next
but some of the questions require the camera and geolocation of the user
which apparently is possible with zoid
and can do this by publishing your survey component to npm and asking them to provide an api key when rendering it inside their app
but I do overall find iframes to be clunky and having a npm package that can be consumed by a client or other app is definitely preferred
which will authenticate them with your api
this is exactly what I am trying to do
Man! If this is possible then I am so glad you responded
and still serve content from a cached source of data (same one that ISR uses)
I've written a SO question on this, posted on reddit, and like half a dozen discord channels haha
yeah which would be Vercel
and you would just send your users to the vercel
if you're like, emailing them a survey link
instead of having the customer embed the survey within their app
Nah its going to be hosted on their site/apps
Okay then you can eliminate the static site for the survey entirely
and purely use the api
(but it may be useful to have around for demos!)
so it would be like the typical way stripe or any SaaS works with doing a yarn add ...
or with a script tag
<script src="example.com/mywidget.js> ...settings </script>
then have it render inside of a div somewhere on their site
`<div id="app-container"></div>"
because you can essentially demo a customers embeddeable widget
in your browser without having to actually embed it
by navigiating to you yourapp.vercel.app/survey/:id
whereas a customer could only reach that data via api calls
So for adding the <script>
I'm not entirely sure how to implement that
as I only focused on a react component
I was initially planning on using next middleware or something to authenticate the api and see if the embedded survey should be shown
How would this be done?
(adds react if it's not already installed)
adds a new element to the dom, or confirms a target one exists
and injects your component into it
React 18 has a new api for doing this and I forgot what it's called l
yup
How would you publish a react npm package?
But regarding the current next app I have, how would I bundle it out?
yeah but with next, like when the yarn build command is ran next basically see's getStaticPaths and builds out multiple files for all of the pages
ideally I would like to package allll of that into one package then the client would only display the survey that is accessible based of their API key correlated to the ID of the survey that was generated
You can encapsulate any code, like getStaticPaths or getServerSideProps into a package and simply import it in your file and then rexport the function
essentially
client npm install -> api key hits my server -> returns generated files
Follow the readme here
Use yalc to add the package into your nextjs project during development
so you dont have to publish it to npm constantly while consuming it
then every time that the call is done from the clients site, it hits the api and vercel returns the latest files (or regenerates them if revalidate is triggered)
So I guess my question here is if this deploys the package, and my next project uses dynamic routes eg., [...question].tsx
would this publish just that skeleton or would it publish the generated surveys from the moment the build command was ran (but not subsequent if changes to the api/json object are made)?
Okay no problem, so my current page structure is like this:
pages
[survey-id]
[...question].tsx
but what is generated, lets say I have 4 clients:
Amazon
Tesla
Airbnb
Nike
Would be like
NikeSurvey.html, -> question1, question2, question3
AmazonSurvey.html -> question1, question2, question3, question4
etc..
if you dont need an iframe then you dont need a static site
and since it is hosted on vercel and i am using getStaticProps
I have revalidate: 30 inside of the function
So Vercel will revalidate the cache and see if any changes in that fetch/api have been made
and you said the customer is using only the react npm package
which communicates with your nextjs api
lets say we change the order of AmazonSurvey questions and replace 3 and 4
then I hit it again, and all the routes would be updated but the client would get
AmazonSurvey.html -> question1, question2, question4, question3,
so why use these pages?
well I built with next so that I could leverage the dynamic pages/router that it has
All of the application exists in the _app and [...question].tsx files
I see
and depending on the return from the api it generates the components required for each question and handles the routing
you know about the /pages/api folder right?
and the contents of getServerSideProps and getStaticProps can be extracted into functions that live elsewhere
So you can move all that to /pages/api and then communicate via rest / graphql api
I am not sure how that translates to the front-end though
to fetch your content
Your requirements just aren't clear sorry
You built a static site, but want to ship to the customer as a react package but don't want to use an iframe to do it
well I think ISR is kind of like a SSR and SSG site combined, right?
i wanted the best of both worlds
You want to use a React package but that wont work with your existing static site because you will be expected to fetch data over rest/graphql to feed it to the react component to render it
so take "react" portions your page files and move it to the react package (which will be published to the customer)
and then take the the "getServerSideProps", etc functions and move them to live as part of your api under /pages/api
Alternatively, ship an iframe
Its not getServerSideProps though, its getStaticProps
Or redefine your requirements
which has the revalidate property
What I said above still applies
sorry if im not explaining this clearly, just excited to be brainstorming on this haha
"revalidate" is just a fancy cache around your page content
Yeah but it also regenerates static files
a cache miss to your api will regenerate your cached api response (which is equivalent to your static file content minus the html)
yes but then that requires the survey to be CSR
No
really?
That would be up to the customer to decide
and on how you architect your component
also, CSR is fine
especially for a widget like this
I guess the way I am thinking about this is the API is just responding with a JSON object and then next is taking that json object and building out the pages and handling the routing from one to the other based off the contents of the object
It's unlikely your customers will be using SSR in the first place I'm just guessing based on experience
"and then next is taking that json object and building out the pages and handling the routing from one to the other based off the contents of the object"
replace this with
"next is communicating with your database / some other api to fetch content, and then returning it as a JSON object"
pages/api/:surveyId/index.ts
gotcha
yeah but then what about the UI/UX of the application?
and skip the react portion entirely
that is your react component
its not even part of your next app
and probably lives in a different repo / codebase
It renders the survey by fetching data from your next api
So are you saying to ditch the [...question].tsx /dynamic routing aspect of it entirely?
aw man I was really happy with the current setup
and after I clarified it
that an iframe will not suffice
then yes, you need to refactor
but it shouldn't be major one
since it's just moving code around right?
and the project will be better for it I hope
because right now I can hit any url that I have hosted and depending on the request it will render out the survey. If I modify the json object in the api, it will regenerate that survey live without a redeploy being done
I was hoping there would be a way to have an npm package act as that sort of middleman
basically hit my hosted site and return a built out version for that survey id and then inject that into a div
yep exactly
and each time that the request is made it fetches that bundle or regenerates and sends that one back
yeah that's the iframe approach
there's just trade offs here to make
and how much effort to spare
I guess what im wondering then is when I used rollup to build the design system, it's on react and i would export each component in an index.js file, and then the npm package has a single entry point
when that is added to a project, I can import the component and it grabs that export
yeah
You know stripe?
Oh yeah
Sort of how their onboarding works for their checkout
it has multiple steps inside of it
I think so
that looks like they render it all out
easier to send people directly to stripe than embedding pieces of stripe in my app
what am i looking at here?
The top one is a company called persona it looks like theirs doesnt use an iframe but it its 'survey-esque'
and then the second is stripe, there are iframes at the bottom but they are all empty,
no problem
can I add you and maybe pick your brain on this some more another time?
you're better off just posting in the help forum or in some other channel here
I think i have dms / friends disabled
on most discords
ah, okay
haha, sure will do
or wherever