Whoops, that made 0 sense because we donāt run stuff on the client in AMP of course so weāre not updating the DOM
Iāve tested it and indeed react-helmet-async will just spit out 1 script tag on the server, even if we add call <Helmet> multiple times - for example for each iframe element in the page.
I think the burden should be on the user to ensure that their content conforms to the AMP spec. Both because it could make the user think that their content is AMP-compliant when itās not and also because there are probably too many restrictions on the AMP content for us to reasonably be able to catch all of them.
In case that we decide to still implement this, I think it should be beyond the scope of the beta version of the AMP package.
Regarding āAMP-aware componentsā, this is what is written down in the implementation proposal:
My questions are: Does the amp entry point still apply? Or this is how we should code this kind of components? Could we create two different components for each mode or is that not possible anymore?
I already implemented the changes using a src/amp.js file for the AMP version of the component but, after reading again the implementation proposal, I think thatās not the way of doing it.
Also, reading the docs is like there are only two entry points: client.js and server.js (apart from index.js). In the case of AMP components, what would be the way of separate the AMP logic from the non-AMP logic? Or are developers forced to ship the same code for AMP and non-AMP components?
Well, we could still create two different components, one for client.js and another one for server.js, and add the AMP logic only to the server.js's component. Is this the expected approach?
In the case of AMP components, what would be the way of separate the AMP logic from the non-AMP logic? Or are developers forced to ship the same code for AMP and non-AMP components?
Someone who wants to have a amp website, will have to define a different set of settings, for that website. So, the codebase will be the same, but the processors and delivery will be different. Or is it allowed to include custom amp components as such the main website has different content than the amp one? AMP noob here
Iāve always imagined that if one wants to have an AMP aware website, by using our amp package, amp processors, and such, including custom components should not be something that would be possible?
Well, not custom components but a different implementation of the same component. If I remember correctly, in the past we did that for complex components like carousel galleries and such that needed a different implementation for AMP.
And, I guess it would be better if you donāt add the AMP code to the bundle as itās only needed in SSR, right? For me, the easiest way to do so is having a different entry point. Thatās my point.
OK, I spent some time thinking about this and, from my point of view, the best option would be to use state.frontity.mode.
First, because it would be a setting that would change the behavior of all the packages installed; therefore, it makes sense to include it in the frontity namespace.
Second, because if we add different āmodesā in the future, for me itās not a good idea to have a different property or flag for each of them, as it should not be possible to have two different modes working at the same time, right? The state.frontity.mode prop would ensure that only a single mode is active.
In the case we want to implement props like state.amp.ssrFallback, what that property could do is to change the āmodeā Frontity works in case some condition is reached.
Haha, sorry. I think I didnāt choose the right words.
I just wanted to say that it would be useful that packages could change the Frontity mode on their own. And that behavior could be controlled using package-specific settings.
Maybe state.apm.ssrFallback is not a good example, I donāt know how that feature is going to be implemented.
I like using frontity.mode, you convinced me David .
Just one thing, if we use it, should we make it more explicit and not use just mode? I am wondering that we are also talking about modes with the Embedded and Decoupled approaches for example, and I guess thatās different right?
Yeah, thatās totally right. We have to come up with a name that is not already used and mode is already used for Embedded and Decoupled modes. It would be confusing.
We cannot use state.frontity.rendering either because it is already used with ssr and csr values.