-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Cannot read properties of undefined (reading 'display') #44028
Comments
Also tried on Node 14:
|
Please provide a reproduction. |
Some errors were related to But the main breaking issue
I can not find any thing related to this |
Also i had to go through a lot of trouble using hit and trial and commenting random things to find the issues as the error message are not related to my code instead those were internal angular errors which i cloud not debug. It would be great if someone could work on this as this is a very crucial thing. |
Please provide a minimal reproduction as otherwise we will be unable to investigate this issue. You can read here why this is needed. A good way to make a minimal repro is to create a new app via |
Here is the Minimal Reproduction of the issue |
I have the same issue on my project. |
@alan-agius4 Can you please update the label so someone can start working on it. |
I did take a look and it doesn't appear to be an issue with Universal, but rather the framework itself. Therefore, I am going to transfer it over to the FW repo for a better triage. |
I've found an extremely simple solution to this, seems like the animation angular/packages/animations/browser/src/render/transition_animation_engine.ts Lines 1629 to 1630 in 155742e
before accessing if(!element.style) {
return null;
} I just tried that and it does seem to work pretty nicely but I doubt that this is the right solution (but it could be?... 🤷) I am not very familiar with SSR/Universal, so I have no idea why the element there doesn't get a |
This was introduced as part of #41059; as noted in the breaking changes for that PR there are some areas where SSR users need to take extra caution. I'm unclear as to why that PR was merged without SSR test coverage, so I'll have to check with the team (and decide whether we should rollback until we have the docs changes ready or not). |
This issue was discovered when debugging angular#44028. The root cause ended up being the TODO here which points out a change in the namespaces between Ivy and VE. As a result, the server renderer was always passing `undefined` as the namespace. The effect of this for angular#44028 was that the SVG element was being created as just an element rather than an SVGElement. [Here][1] is the code reference for what happens in Domino. Finally, when the animation attempts to apply to the SVG element, it fails to because the element doesn't have a `style` property. Resolves angular#44028 [1]: https://github.com/fgnass/domino/blob/12a5f67136a0ac10e3fa1649b8787ba3b309e9a7/lib/Document.js#L232-L239
This issue was discovered when debugging angular#44028. The root cause ended up being the TODO here which points out a change in the namespaces between Ivy and VE. As a result, the server renderer was always passing `undefined` as the namespace. The effect of this for angular#44028 was that the SVG element was being created as just an element rather than an SVGElement. [Here][1] is the code reference for what happens in Domino. Finally, when the animation attempts to apply to the SVG element, it fails to because the element doesn't have a `style` property. Resolves angular#44028 [1]: https://github.com/fgnass/domino/blob/12a5f67136a0ac10e3fa1649b8787ba3b309e9a7/lib/Document.js#L232-L239
…erer Support for namespace URIs rather than short namespace names was added in angular@2b9cc85 to support how Ivy passed around the namespace URI rather than short name at the time. As a side-effect, this meant that namespace URIs were supported by the default dom renderer as part of the public API (likely unintentionally). It did not, however extend the support to other parts of the system (setAttribute, setAttribute, and the ServerRenderer). In the future we should decide what exactly the semantics for dealing with namespaces should be and make it consistent. fixes angular#44028
…erer Support for namespace URIs rather than short namespace names was added in angular@2b9cc85 to support how Ivy passed around the namespace URI rather than short name at the time. As a side-effect, this meant that namespace URIs were supported by the default dom renderer as part of the public API (likely unintentionally). It did not, however extend the support to other parts of the system (setAttribute, setAttribute, and the ServerRenderer). In the future we should decide what exactly the semantics for dealing with namespaces should be and make it consistent. fixes angular#44028
…m renderer Support for namespace URIs rather than short namespace names was added in angular@2b9cc85 to support how Ivy passed around the namespace URI rather than short name at the time. As a side-effect, this meant that namespace URIs were supported by the default dom renderer as part of the public API (likely unintentionally). It did not, however extend the support to other parts of the system (setAttribute, setAttribute, and the ServerRenderer). In the future we should decide what exactly the semantics for dealing with namespaces should be and make it consistent. fixes angular#44028
…m renderer (#44914) Support for namespace URIs rather than short namespace names was added in 2b9cc85 to support how Ivy passed around the namespace URI rather than short name at the time. As a side-effect, this meant that namespace URIs were supported by the default dom renderer as part of the public API (likely unintentionally). It did not, however extend the support to other parts of the system (setAttribute, setAttribute, and the ServerRenderer). In the future we should decide what exactly the semantics for dealing with namespaces should be and make it consistent. fixes #44028 PR Close #44914
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🐞 Bug report
What modules are related to this issue?
Description
On running
npm run dev:ssr
the code is compiled successfully but when i open the link then error occurs which is added in the exception below.I have imported NoopAnimationsModule in app.server.module and i have also separated the app.module.ts and app.browser.module.ts
🔥 Exception or Error
🌍 Environment
The text was updated successfully, but these errors were encountered: