Server side rendering support about css-vars-ponyfill HOT 10 CLOSED

No worries, @waterplea. Just wanted to make sure we addressed the issue before publishing.

New version (1.16.3) has been published to NPM.

Thx!

from css-vars-ponyfill.

Thanks for sharing your findings, @waterplea. Interesting stuff. A few comments...

1. Check the options.onlyLegacy docs to see how to handle older versions of Edge. By testing the user agent string for the existence for "Edge" followed by a version number, you can easily tell the ponyfill to treat older versions of Edge as a legacy browser. Certainly not the only way to do it, but it keeps things nice and tidy.
2. Libs like detect-node could be a good alternative for detecting what environment the ponyfill is running in.
3. mergeDeep is used instead of Object.assign because the latter is not supported by legacy browsers. It can be transpiled to legacy-compatible code via @babel/plugin-transform-object-assign but I'm not currently using that transform. Point being, to maintain legacy compatibility you should use mergeDeep.
4. The readyState issue could also be resolved using detect-node . If the ponyfill is running under Node, there is no readyState.

Happy to discuss server-side rendering further, but I wanted to share the above feedback before I dive in (which probably won't happen until after the holidays).

from css-vars-ponyfill.

1. I know but ponyfill check CSS and CSS.supports which is not available for server side.
2. It looks like you try to make you ponyfill dependency-free so adding a lib would not be an option for you.
3. I know that it is not available for old browsers, that's why I've made an early return with if (Object.assign) {, if it's not available — it falls back to mergeDeep.
4. In Angular Universal (server side Angular) it is typical to use Domino library and that emulation has readyState which is loading. Basically now I set it to interactive when I call ponyfill and immediately after to what it was. It's a bit hacky but seems fine since it's just an emulation. If you could handle it somehow in your method — it would be cool, but very optional. The real problem is mergeDeep treating document emulation as object and going into infinite loop.

from css-vars-ponyfill.

Apologies for the delayed response, @waterplea. Getting back on track after the holidays...

After thinking about this a bit more, I'm not sure I understand the advantage of adding SSR support to this ponyfill when postcss (along with the postcss-custom-properties plugin) already handles transforming custom properties to static values on the server. Postcss is also well integrated with bundlers like webpack/rollup and the CLI. Perhaps there is something Angular-specific that I am unaware of or a particular use case that postcss cannot handle?

I can think of only two scenarios where SSR + css-vars-ponyfill could provide functionality not available with postcss:

1. Processing external <link> stylesheets
2. ShadowDOM support

I believe the first option would work without issue because js-based DOM implementations like jsdom and domino provide XMLHttpRequest support. ShadowDOM support would not work because the polyfills required don't support legacy browsers. That means we're left with just <link> support, which I can't imagine is a common issue given how easy it is to work around (just a local copy for server-side processing).

FWIW, I'm not opposed to making the changes but I'd like to clearly understand what benefit SSR support provides over existing options before investing dev time.

Thanks!

from css-vars-ponyfill.

Hi @jhildenbiddle

Angular is pretty good at being platform agnostic. You have the same app pretty much, just a few configurations around it — and you get all the same components rendering at the server as on the client. You even can retain events/focus so when server-side rendered content is immediately delivered you can start filling forms and when the whole app arrives the transition is seamless. You could probably write some specific configuration to precalculate custom properties, I'm not really sure what is the pipeline with angular and styles — I'm not that versed with infrastructure but the philosophy behind Angular and SSR is that you write your app in a way that works in both environments.

from css-vars-ponyfill.

I did a little more research on this...

The source of confusion (for me, at least) is that tools like react-create-app and @angular/cli already include both webpack and PostCSS which are the tools necessary to transform CSS custom properties to static values on the server. Simply adding the postcss-custom-properties plugin is all that needs to be done.

Unfortunately, this isn't as easy at it sounds.

Adding a new plugin requires modifying configuration files, but these configuration files are not easily modified when apps are created using create-react-app or @angular/cli. These tools are designed to hide the build complexity from users, and as a result prevent users from modifying their internal configurations. It seems that the inability to make even minor config changes has been an issue that users have struggled with for a while now. An "eject" option was once available for Angular users that would expose all configuration files, but going this route means taking on responsibilities for all of the complex build configuration (Angular is no longer managing for you). This option has been disabled in Angular 6 so new tools have been created to fill the gap, but it seems like folks are struggling with these as well.

Yeesh.

The summary is that I think there is value in adding SSR functionality to the ponyfill. If it were easier to add PostCSS plugins to apps created with create-react-app and @angular/cli then I would argue that postcss-custom-properties is a better server-side solution due to the way it processes and outputs CSS. Until then, perhaps css-vars-ponyfill can make life easier for folks by including SSR support.

I'll dive into this next week. Thanks, @waterplea.

from css-vars-ponyfill.

Thanks, @jhildenbiddle. Like I said, the only thing really preventing it from working as is — the merge deep function. The rest is quality of life — I only encountered a small inconvenience with document.readyState dependency that I mentioned in the first post while firing up a starter app for Angular.

from css-vars-ponyfill.

An updated version of the ponyfill is available via the "ssr" branch.

To install via NPM:

npm i -D jhildenbiddle/css-vars-ponyfill#ssr

This version contains one change: the deep merge previously used to merge default and user options has been replaced with a shallow merge (using Object.assign). This is a non-breaking change that should address the main issue you were experiencing with Angular and domino.

Regarding the document.readyState issue, this is not an issue with other JavaScript-based DOM implementations like jsdom which are also used for SSR. The document.constructor === Object fix suggested also returns inconsistent results in these two libraries (true for domino, false for jsdom), so this check is not a reliable way to test for server-side rendering. I'd prefer to avoid adding code that is library (Angular, React, Vue, etc.) or environment (Browser, Server, Node, etc.) specific unless absolutely necessary, so in this case I think it's best to manage domino's readyState within your application.

FWIW, I've also added jsdom to the list of browsers used for automated unit testing. All tests pass without issue. I would add domino as well, but the necessary launcher for karma was release only a few days ago and based on this issue it looks like it isn't ready for prime time yet.

Give the "ssr" branch a shot and let me know how it works. If all goes well I'll merge it and publish a new version to npm as soon as I get the thumbs up.

from css-vars-ponyfill.

@waterplea ☝️

from css-vars-ponyfill.

Right, sorry @jhildenbiddle, forgot to give it a shot. Works fine with my setup, pretty sure it should work with other SSR frameworks. Thank you!

from css-vars-ponyfill.