Support sending styles in Hyperview fragments #1074
Replies: 7 comments
-
|
One other approach we could consider is to allow Another question: should |
Beta Was this translation helpful? Give feedback.
-
I thought about this a bit, I think part of one-off styling is really bound to how the system that generates your markup is organized. With the solution we're currently exploring for our backend, we'll have the ability to collocate styles with components, so that'll fill the need here. It's true that when writing the XML manually, it's not the easiest right now to associate a style with an element, but is this a use case you think is worth optimizing for? Also, as of right now, not every Hyperview components are rendering children elements, so that might also make it unpredictable when this would work - or would be at the expanse of a larger refactor.
By global settings, you meant the document, right? As of right now, styles are already scoped to the doc. Could you list some of the benefits you have in mind for scoping the styles to the fragment only? |
Beta Was this translation helpful? Give feedback.
-
The use case is when we sometimes have a one-off need, for example if a specific element needs a custom width. I'm noticing our design system styles are getting littered with some of these one-off styles, which is bloating the payload for all screens. Also worth keeping in mind that when adding features to Hyperview core, the open-source users won't have the benefit of our internal system for rolling up all styles. So I could see some users relying on co-located styles with their components, even if we're not doing that ourselves. I agree it may not be something we need to add immediately, but I want to at least keep the door open for this sort of design in the future.
This is probably best shown with an example. I believe <doc xmlns="https://hyperview.org/hyperview" >
<screen>
<styles><style id="main" flex="1" backgroundColor="red" /></styles>
<body>
<view style="main" / > <!-- this will be red -->
</body>
</screen>
<screen>
<styles><style id="main" flex="1" backgroundColor="blue" /></styles>
<body>
<view style="main" / > <!-- this will be blue -->
</body>
</screen>
</doc>So there's a precedent that the styles apply only to the context where they are defined, in this case the <doc xmlns="https://hyperview.org/hyperview" >
<screen>
<styles>
<style id="main" flex="1" backgroundColor="red" />
</styles>
<body>
<view style="main"> <!-- this will be red -->
<fragment>
<styles>
<style id="secondary" color="green" />
</styles>
<body>
<text style="secondary">World!</text> <!-- this will be green -->
<view style="main" /> <!-- this will be red, using style from parent screen -->
</body>
</fragment>
<text style="secondary">Hello</text> <!-- this will not be green -->
</view>
</body>
</screen>
</doc>Now that I've written out this example, I do see some potential issues, which means maybe we don't want to do this.
One other idea to explore: since the desired effect is to add styles at the screen-level, perhaps this could be done with a behavior. Something like this: <view>
<behavior trigger="load" once="true" action="add-styles">
<styles>
<style id="secondary" color="green" />
</styles>
</behavior>
<text style="secondary">World!</text>
</view> |
Beta Was this translation helpful? Give feedback.
-
|
Some alternatives:
<view href="#">
<style backgroundColor="red">
<modifier pressed="true">
<style backgroundColor="blue" />
</modifier>
</style>
<text>
<style color="yellow">
<modifier pressed="true">
<style backgroundColor="green" />
</modifier>
</style>
Hello world
</text>
<doc xmlns="https://hyperview.org/hyperview">
<screen>
<styles>
<style id="primary" color="blue" />
</styles>
<body>
<text style="primary">Hello</text>
<style id="primary" color="red" />
<view>
<style id="primary" color="green" />
</view>
</body>
</screen>
</doc>
|
Beta Was this translation helpful? Give feedback.
-
|
Amongst the alternatives listed, I think option 1 for inlined styles is the most straight-forward.
It may help to introduce a |
Beta Was this translation helpful? Give feedback.
-
I think the general practice in CSS is to avoid rendering If we were to implement this approach, we probably would need to implement a render-blocking mechanism, though maybe we wouldn't need it if we're never planning on supporting chunked responses (i.e. is there any point in doing render blocking if we already have the whole document loaded, so that every styles are available before rendering starts?) |
Beta Was this translation helpful? Give feedback.
-
|
For anyone watching this issue, a custom behavior action |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Right now, the styles definition is represented under the
<styles>element, which by spec requires to be an immediate children of the<screen>element. Hyperview fragments by spec only return elements that can be appended to a element.Proposal: define a new
<fragment>element, modeled after the<screen>element, that will serve the purpose of nesting content and styles in two separate elements. For example:Current
Proposed
We would need for this to update the existing parsing code to change the validation logic while preserving support for the old format, then extract the stylesheet here (like it's done here) and merge it in the existing stylesheet (stored on the React state).
Beta Was this translation helpful? Give feedback.
All reactions