Fluentui: UI Fabric evolving to Fluent UI

[mielke]

I wanted to start an issue to collect any questions or feedback the community might have.

Today, we announced that UI Fabric is evolving into Fluent UI: https://developer.microsoft.com/en-us/office/blogs/ui-fabric-is-evolving-into-fluent-ui/

We are looking forward to any feedback/questions.

• Fluent UI/React team

[StfBauer]

Please focus in future on a real HTML/CSS Web-based Fluent UI Framework and not a React-based one. It will improve the quality of Fluent UI and helps to refactor from small components like a single drop-down item to dropdowns to larger components.

While there is a lot of developers that use React there are even more that don't.

[wellbeck190]

Should I use Stardust or Office Ui Fabric React for a new project?

[KyleBastien]

Do I need to rename all my package imports to something new?
No. Package names will stay the same as a result of the merge and rename effort. We’ll continue releasing all UI Fabric packages as we do today. We’ll also alias publish the same packages under a new name, so that at any time you can use the new @fluentui/react package with no breaking changes.

Given this, what about existing users of the @fluentui/react package, who were previously using the Stardust library? Are we going to need to change our package imports?

[sushruth]

Also, while importing components, how can we differentiate between similar components like, a stardust/fluentui button and a uifabric button?

What is going to happen to ShortHandProps way of composing Components ?

Will this combined package use fela or @uifabric/styling ?

[aneeshack4]

@sushruth @KyleBastien @wellbeck190 @StfBauer thanks for reaching out to us with questions and feedback! @dzearing and @levithomason have the latest info on best practices and will be able to best answer your questions.

[sushruth]

@dzearing @levithomason - can you help answer my questions from here - ?

Also, while importing components, how can we differentiate between similar components like, a stardust/fluentui button and a uifabric button?

What is going to happen to ShortHandProps way of composing Components ?

Will this combined package use fela or @uifabric/styling ?

[dzearing]

To provide some background on what's happening, we will be posting a more thorough FAQ on these questions shortly in our wiki. But here are some answers to the specific questions:

We're converging our packages under the @fluentui NPM scope. As a result:

1. The office-ui-fabric-react v7 package is now additionally published as @fluentui/react v7. (The current package name will still be published as well, so there will be no disruption for customers.) Use @fluentui/react for new projects. We will be scrubbing examples and website content over the next few weeks.

2. The Stardust package has been published as @fluentui/react-northstar. If you're creating a new Teams project, please use @fluentui/react-northstar.

Neither Fabric or Stardust are replacing each other. We are working together to merge the two libraries, combining the best of both into a single library of components. It will take a few iterations of moving each closer to get there.

Some of the major problems we are tackling:

• Shared tooling and utilities. Avoid bulky bundles by unifying our shared utilities.

• Shared theming. Allow one theme to be defined for rendering any of our shared components.

• Runtime performance. Improve render speed by leveraging css variables to avoid costly CSS in JS computation overhead.

• Converging components and props. Align component names. Create predictable props for components. Improve composition through shorthand syntax and configurable slots.

• Separation of styling from the components. Provide non-React developers with themable css styling that can be used in any framework scenario, even for static HTML pages.

We do also want to address the needs of non-React developers. We are coordinating with a few teams on adding a web components solution, hope to have more news on this soon.

[dzearing]

Also, while importing components, how can we differentiate between similar components like, a stardust/fluentui button and a uifabric button?

We have separate package names for the two libraries. That should at least help differentiate. If you're using parts of both with some overlaps, recommend setting up a single file in your project that exports the components you're using, so that you can have one place to tweak which thing you use, and if you need to wrap them with customizations. Then your app code isn't pulling directly from the libraries, but from your single set of exports. Will help with future tweaks as well.

What is going to happen to ShortHandProps way of composing Components ?

I can't give definitive details as the concept of slots is not finalized. We will definitely have a shared solution. There are some discussions about whether custom slot content is provided inline by { children: (C, p) => <.../> } or something separate. There are performance vs ergonomic tradeoffs. We want a consistent solution though and will certainly bring much of it forward. Are there things you like that we should preserve? Please provide feedback on what you like about the syntax. :)

Will this combined package use fela or @uifabric/styling ?

This is a critical issue for us to unify on. Both Fela and MergeStyles have their pros and cons. CSSinJS is useful but brings a host of problems - mainly runtime performance when used in bulk, which forces us to add additional caching layers, which ends up adding bulk. So... what we like is: css + css variables for theming. It creates a far more ergonomic configurability story (replace these variables instead of hunting for selectors) that is a ton faster to render (no style re-evaluation, only css variable definition.) We need to still consider IE11 users, so we also need to make sure what we do doesn't exclude that, but also doesn't penalize everyone else. Thoughts?

[MJomaa]

We do also want to address the needs of non-React developers. We are coordinating with a few teams on adding a web components solution, hope to have more news on this soon.

That's exciting! Finally :)

[NikitaIT]

@dzearing

We need to still consider IE11 users, so we also need to make sure what we do doesn't exclude that, but also doesn't penalize everyone else. Thoughts?

Use the babel plugin to replace css variables with functions that return either variables or constants depending on the browser?

[NikitaIT]

@dzearing

I can't give definitive details as the concept of slots is not finalized. We will definitely have a shared solution. There are some discussions about whether custom slot content is provided inline by { children: (C, p) => <.../> } or something separate.

From my experience with vue, I am more than sure that slots, especially scoped, make component extensibility difficult. If you make the components more independent and leave the layout composition step to the end, it’s easier to get more flexibility.
For example, for control with an icon or label:

// 1
const formInput = () => (<XLabel for={id}>
<XInput id={id} />
</XLabel>);
// 2
const labeledInput = () => (<>
<XLabel for={id}></XLabel>
<XInput id={id} />
</>);
// 3
const iconedInput = () => (<XInputContainer>
<XIcon />
<XInput id={id} />
</XInputContainer>);

instead of

// 1
const formInput = () => (<XInput id={id}>
() => ({ container: (p, c) => <XLabel for={id} />{c}</XLabel> })
</XInput>);
// 2
const labeledInput = () => (<XInput id={id}>
() => ({ before: (p, c) => <XLabel for={id} />{c}</XLabel> })
</XInput>);
// 3
const iconedInput = () =>  (<XInput id={id}>
() => ({ before: (p, c) => <XIcon />})
</XInput>);

or instead of

<XInput id={id} label="xxx" icon="xxx" clearIcon="xxx" iconPosition="before" labelPosition="top" >

[MJomaa]

The scenario I saw a couple times now (yesterday again):

• Primarily .NET / .NET Core company.
• Is using everything from Microsoft including Windows 10, Office 365, Azure Hosting, Azure Services, Azure DevOps, Microsoft Teams, IIS, MSSQL, etc.
• Is building enterprise software which requires a lot of form elements.
• Want to overhaul their old software or build a new one with a "Microsoft look" because they also like how Office 365 looks and everything in the company is Microsoft anyway.
• Angular is better at handling forms and is more familiar for .NET/Java devs (Services, DI, OOP, forced TypeScript). If the company is involved in SharePoint development they adopt React but more often then not they just keep their old interface or use Angular with Bootstrap.

Hope that helps.

I see that the Power BI Web team is using Angular with Material Design. How are they doing it? Custom components that look like Fluent UI?

[NikitaIT]

I will supplement my message about the slots.
Slots should be a good choice for components that introduce indestructible, true always without "except" restrictions. Related framework parts of the library. This is in accordance with the principle of "Don't call us, we'll call you." However, fluentui is provided to clients as a library, and not as a framework, so it would be logical to prefer a flexible composition for all components used by the client library, instead of more stringent composition restrictions created by slots. By itself, the use of JSX is already a similar restriction, it should not be aggravated.

[andrantis]

Is there any plan to have Angular components the same way you have react components? I found out about Fluent UI and I think it looks great. Nice work!

[jmls]

We do also want to address the needs of non-React developers. We are coordinating with a few teams on adding a web components solution, hope to have more news on this soon.

That's exciting! Finally :)

any news on this ? Would love to use this lib but pretty much committed to angular 9