SSR/Universal support for material-community-components
Krgauravfreelancer opened this issue · comments
Describe the bug
When I am trying the SSR/universal on angular 7 application, I am getting window is not defined errro.
See Full error
ReferenceError: window is not defined
at ~\node_modules\material-community-components\bundles\material-community-components.umd.js:2898:14
at \node_modules\material-community-components\bundles\material-community-components.umd.js:2:68\node_modules\material-community-components\bundles\material-community-components.umd.js:5:2)
at Object. (
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! qimtekui@0.0.0 serve:ssr: node dist/server.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the qimtekui@0.0.0 serve:ssr script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! ~\Roaming\npm-cache_logs\2019-03-21T18_01_35_894Z-debug.log
To Reproduce
Steps to reproduce the behavior:
Just add a single control mcc-color-picker and make the angular 7 application in SSR.
Expected behavior
It should work fine and does not give this error
Desktop (please complete the following information):*
- OS: windows 10 x64
- Browser : NA
Please help ASAP
yup i'm seeing this too
oddly enough, I only see "window" used in scrollspy, not in mcc-color-picker
@captaincaius I think is because all the modules are bundled into one bundle. If they were using ng-packagr's "secondary entrypoints" then this would only be a problem when using the scrollspy module. But I guess this is another issue.
@ng-toolkit/universal has a wrapper for window. @tiaguinho would you consider adding this as a dependency and using that? or would you want to implement a similar solution in this library? I am happy to prepare a pull request for either.
@douglasward yes you're right - there's actually two problems -
- the legit scrollspy problem, and
- the fact that all other components have to suffer b/c of it
I ended up forking and pulling off just the component I needed just to get the job done, but eventually I'd like to undo that.
TBH I would personally not like for that dependency added and I like your first suggestion better - packaging it properly and also making scrollspy SSR-friendly.
If you have experience with the packaging part, maybe you can help with that. I could probably throw together a quick PR for making scrollspy SSR-friendly, but it would mask the packaging problem.
Components will be build separated in version 7.2.0.