Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Simple, robust and performant API #597
This PR probably introduces the biggest shift since first releasing the React bindings for Fela.
The new way to go is
If one of the following checks doesn't make sense due to the type of PR, just check them.
Stardust UI has long-term lofty goals to produce a specification for standardized UI components and component anatomy. With this specification and component anatomy canon, we are able to provide framework agnostic utilities for accessibility, styling, and state management. These utilities are shareable across teams and platforms and have the potential to normalize implementations and share features/fixes across frameworks.
Fela is currently the library being used in Stardust for styling. We love the modular approach and focus on performance. It offers us the best chance so far to hitting our goals.
You can see the infancy of these ideas in Stardust's React bindings at stardust-ui/react.
At Microsoft we are using Stardust to forge our future component standards and practices. Initially, Stardust is supporting Teams. All of the topics we are tackling are in support of applications that need enterprise level components that can meet the demands of all users globally.
We've had mostly success with fela, but have also not used most of the utilities scheduled to be deprecated. Because of our requirements, we are mostly using the renderer directly in our own binding. We'll likely be focused on the renderer moving forward as we have our own robust base component patterns that we need to support.
I should also mention that we are striving to reduce the number of components in the render tree. This was a major factor in choosing to use the renderer directly. We are also considering ways to pass the renderer and theme in a single context channel. In fact, we are leaning toward having a single context channel for Stardust altogether.
The motivations for a single context channel are also due to trying to reduce the number of components in the render tree.
I am frightened by the desire to refuse to use the
@sgrishchenko Hmm, I especially hate the multi-rule approach as I again have to name that shit (rather than mapping styles to components directly). You do not gain any benefit from connect expect for possibly mixing 2 different concerns. If you're styling a complex component with a single connect, have you considered composing smaller components? Apart from that, you should never style components with business logic, that's 2 separate concerns and can lead to super complex components (ofc thats just my opinion, but that might be the reason why you prefer connect at all).
In general, I would love to get rid of some complexity and cC / connect seem to be the biggest issues here. How about having separate packages with dedicated ownership? (Github should have tools for that). If you're happy maintaining connect/createComponent, there's nothing keeping you from doing that (maybe we should still refactor/simplify both, but yeah).
Nevertheless, would you be willing to maintain those hocs (maybe as a separate package here, react-fela-hocs or sth. like that)
@rofrischmann This is suitable for me and I will be happy to do it. I don't like