Order of properties can change in different environments #199
Comments
|
Also, I noticed that the generated selector is the same, which I believe implies that the styles are passed to Aphrodite in the same order in both environments. |
|
I'm thinking that anywhere object keys are used, they will need to be manually sorted to preserve developer intention and consistency across environments and browsers. |
|
Note that this includes any usage of |
|
@lencioni Huh! That's very... annoying. I'd love to get some more information about the two environments you're rendering the different styles in. Are you server-side rendering in one, or is it two different browsers? Also, could you try updating to the current version of Aphrodite (v1.1.0) and see if you're still experiencing the problem? |
|
Ah, yes, in production we are server side rendering. That is almost certainly the key difference here. I'll work on updating Aphrodite, but it might take me a while. |
|
Property key ordering also changed noticeably in a specific version of v8, which means node-to-chrome across that boundary, or node-to-nonv8, will have this problem. |
|
Okay. I've feel like I've seen that happen before also when server-side rendering :(. Do you know what version of node you're using on your server? And what browser are you using? I haven't seen it in a while, so maybe some combination of node/aphrodite upgrade fixed it, or maybe we're just not triggering it any more. @ljharb Huh, interesting! I didn't know that it had changed. Do you know when that happened, or can you find docs about it? |
|
@xymostech object property ordering became specified in ES6, so all engines will eventually have consistent ordering, but it'll always be a good practice to not rely on key ordering. We were using node 4.2.4 and now 4.6.2. |
|
I think it is important to stabilize the sorting of these styles, but it might also be interesting to explore a more advanced merging strategy for shorthand properties. e.g. merge |
|
Indeed, I think both would be a good idea. |
|
@lencioni while that sounds interesting, I think I'd like to avoid doing merging into the shorthand properties like that because it would probably involve understanding a lot of CSS semantics, which we're trying to avoid in Aphrodite. Going the other way seems more interesting to me, though. If you specified |
I'm looking into doing this sorting, and I'm not really sure what this means. Just plain sorting the properties obviously isn't what we want, because then |
|
Right, exactly. If the user provides the keys in object form, there's no way to know what sorting they intended. A better approach would be if the user provided a |
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
Summary: Key ordering in objects can be different in different environments. Sometimes, this causes problems, like where styles generated on the server are not in the same order as the same styles generated on the client. This manifests in problems such as #199 This change lets users manually fix instances where the ordering of elements changes by specifying their styles in an ES6 `Map`, which has defined value ordering. In order to accomplish this, an `OrderedElements` class was created, which is sorta like a `Map` but can only store string keys and lacks most of the features. Internally, `Map`s and objects are converted into this and then these are merged together to preserve the ordering. Fixes #199 Test Plan: - `npm test` @lencioni @ljharb
I am noticing a difference in how the style properties are ordered between a development environment and a production environment. Essentially, I have a couple of styles that look like this:
I am applying them to my element like this
css(foo, isBar && bar).In my development environment (a story in react storybook), the component is styled as expected, with 0 margin all around except for the 16px of margin on the right. However, in production, my 16px right margin is missing. Looking at the generated styles, I can see that all of my properties are there, but the order is different.
In storybook:
In production:
I also have some more styles than just margin, but I am just mentioning these because it highlights the specific problem. Here's the specific CSS that is generated in development (whitespace added for readability):
and in production:
Any ideas what might be happening here or where to look? It seems that there might be some code that expects the order of things to be stable when that is not the case. Or perhaps we are transforming (Babel) or polyfilling something slightly differently in these two environments?
Aphrodite v0.5.0
The text was updated successfully, but these errors were encountered: