docs(rfcs): Recipes #25139
docs(rfcs): Recipes #25139
Conversation
sopranopillow
added
Fluent UI react-components (v9)
Type: RFC
sopranopillow
changed the title
📊 Bundle size report🤖 This report was generated against 8af3b4d39ad1649ceeb5a2797ad00aa3f0b1547c |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8a8180b:
|
Asset size changesSize Auditor did not detect a change in bundle size for any component! Baseline commit: e799d65bcc8a71db789a41bda7240103f3bf5de7 (build) |
khmakoto
left a comment
khmakoto
left a comment
There was a problem hiding this comment.
My first thought is that I like the recipe approach of option 3. However, if we go that route I think we need to think more thoroughly about what the API would look like, maybe using that media object example.
rfcs/react-components/components/simple-component-implementation.md
Outdated
Show resolved
Hide resolved
rfcs/react-components/components/simple-component-implementation.md
Outdated
Show resolved
Hide resolved
| - The desired design is achievable adjusting the props of the inner components. | ||
| - It doesn't have complex accessibility requirements. | ||
| - It doesn't have strict design requirements. | ||
|
|
There was a problem hiding this comment.
Consider detailing the core considerations you think the team should use to make a decision of one approach vs. another. Here's some examples:
- The decision should encourage components that provide high value beyond general purpose layout.
For example, v9 deprecated and did not reimplement Stack. Stack provides low value over using flexbox directly and was very general purpose.
- The decision should encourage components that are general purpose enough to be core to Fluent
Components like Field provide label, error message, and input component layout and coordination that can be used in many form scenarios. Components like a SharePoint file-list specific Card might not be reusable by others easily and maybe should live outside the core of Fluent and be implemented by the team that uses them. This brings up a secondary question of should our decision favor a pattern that other developers building on top of fluent should use?
- The decision should prefer a solution that builds on top of our composition model.
We have a composition models that leverages slots, hooks, and context to make customization and replacement possible. Which solutions leverage the existing composition model the best to maintain developer productivity and extensibility.
rfcs/react-components/components/simple-component-implementation.md
Outdated
Show resolved
Hide resolved
|
|
||
| ## Detailed Design or Proposal | ||
|
|
||
| ### Option 1: Recipes section in docsite |
There was a problem hiding this comment.
I love the idea of recipes. I have found that the migration shims didn't work very well as recipes because people want to keep up to date with the latest and best version. A recipe should have lots of stuff left as work for the reader to fill in. If we find that people are just cut-and-pasting the code as-is everywhere, then it should probably be a component.
|
|
||
| A great example of a recipe is the [Media Objects recipe](https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_cookbook/Media_objects) by MDN. | ||
|
|
||
| #### Folder structure inside docs |
There was a problem hiding this comment.
Storybook doesn't make recipes easy to show as the code-behind is limited to what is within the story. Maybe we need to figure out ways to better show recipe code in storybook or find a better way to publish them.
rfcs/react-components/components/simple-component-implementation.md
Outdated
Show resolved
Hide resolved
|
|
||
| ### Option 2: We provide the component | ||
|
|
||
| For this option, we would implement the component and provide it like any other component. |
There was a problem hiding this comment.
just to clarify, do you mean that we would implement Persona or a generic Media layout component ?
There was a problem hiding this comment.
If we go with this option, we will provide a Media Layout component and a Persona component.
There was a problem hiding this comment.
Have we checked with design if there is an appetite for a reusable media layout on their side? It would requirement commitmment from both us (to implement and maintain it) and design (to design with it in mind)
|
|
||
| return ( | ||
| <div className={mediaObjectClassNames.mediaObject}> | ||
| <Image |
There was a problem hiding this comment.
Design can sometimes have specific requirements on the inner components (i.e. Avatar), how do we handle such cases with a style hook based solution ?
There was a problem hiding this comment.
This would be an example a part of the recipe we leave up to the user. While option 3 gives a hook, there might be some things we cannot provide, and this could be confusing.
| #### Cons | ||
|
|
||
| - More code to maintain. | ||
| - Could bring more issues by being hard to follow. |
There was a problem hiding this comment.
You mentioned accessibility issues for Option 1, but I think it's still an issue for this option as it provides only styling.
|
Just to clarify: what problem we are trying to solve? Create/maintain less components components that are easy to build? I think that recipes is a good idea as it enhances the idea of prototypes in v0 (https://fluentsite.z22.web.core.windows.net/0.64.0/prototype-text-area-autosize): we show our vision and direction there for partners. Did you consider to add forth option with contrib package? For example, if we want to maintain less - we can create components, but encourage partners to maintain these additional bits. |
* master: (22 commits) fix(react-menu): removes exposing of internal type FluentTriggerComponent (microsoft#25410) fix(react-popover): removes exposing of internal type FluentTriggerComponent (microsoft#25411) applying package updates fix(react-tooltip): removes exposing of internal type FluentTriggerComponent (microsoft#25409) chore: Reducing bundle size of Stack by moving selector used in multiple places to local const (microsoft#25429) docs(rfcs): Simple component implementation (microsoft#25139) Fix migration publishing (microsoft#25422) Integrate storywright for story tests - As part of exploring screener alternative (microsoft#25399) fix(react-utilities): exposes internal methods used in API surface (microsoft#25406) fix(react-dialog): removes exposing of internal type FluentTriggerComponent (microsoft#25408) fix(react-context-selector): exposes internal type ContextSelector (microsoft#25404) fix(react-aria): exposes internal leaking types (microsoft#25403) fix(react-shared-contexts): exposes internal leaks used in the API surface (microsoft#25405) fix(react-positioning): exposes new typings to avoid exposing internal methods (microsoft#25407) applying package updates fix: Allowing DatePicker to be focusable within FocusZones by default (microsoft#25428) fix: Pad in slider so the thumb does not render outside the bounds of the root element (microsoft#25378) feat: Add enableScopedSelectors prop to Stack that, when true, makes the Stack styles selectors be more scoped to not be as expensive in style recalculation (microsoft#25397) fix(react-avatar): Remove gaps between AvatarGroupItem/OveflowButton and its outline (microsoft#25382) fix: Combobox text attribute ignored when empty string is passed (microsoft#24665) ...
sopranopillow
changed the title
pretty late to the party as I was not in the loop (I do apologise). This is a great suggestion @layershifter ! From experience proposed solution will add additional maintenance for the core team. This more "complex" scenarios should be driven by community/partners as they understand the best their needs. Core team can/should be leveraged as SME and help out partners achieve what they wanted in re-usable manner whenever possible. the approach could look like following:
|
* docs: Adding simple-component-implementation RFC * adding requested changes * updating based on feedback * minor change * cleaning up RFC
* docs: Adding simple-component-implementation RFC * adding requested changes * updating based on feedback * minor change * cleaning up RFC
9 participants
Problem statement
Currently we don't have clear guidance on how to implement or if to implement simple components that could be implemented by the user with already created components. This RFC will give guidance on what to do when we have such components and asks for feedback on which option to follow.
Preview