Reboot Fluent UI Blazor Community project?

[vnbaaij]

See #2419 for reference

In summer last year, an organization was created here on GH to create a community extensions project for the library. As I said in that earlier discussion, we (as in Denis and I) can't be directly involved in that. Organization, and support would then ultimately still be on us and we really can't handle that.

Due to circumstances, that project then didn't really took off, but I still think it could be interesting to have his. Especially now that we have issues and discussions like #3562 and #3631 and others being raised.

@StevenRasmussen, @PascalVorwerk, @oneolddev, @MarvinKlein1508 (or others of course!) would any of you be interested in being added to the organization as an admin and startup and lead such an extension project?

[MarvinKlein1508]

Hi @vnbaaij,

As I've mentioned before, I try to help out wherever I can. I really like the FluentUI library and I'm happy to assist you on this journey.

Once v5 becomes available, I plan to start rewriting an old application of mine using the new FluentUI library. I believe I’ll need some custom components then as well. One idea I already have is adapting my custom implementation of a SignaturePad to follow FluentUI styling:
https://github.com/MarvinKlein1508/SignaturePad

I still have a few questions regarding this topic, and it would be great if you could clarify them:

1. What exactly do you expect us to do?
2. Will there be one large repository, or will the projects be separated into different repositories (e.g., like BlazorExtensions)?
3. When should a component be part of the community components instead of the core project?
4. Will this be entirely community-driven, or will you also be available for regular discussions and coordination?

[vnbaaij]

• What exactly do you expect us to do?

Own it. Drive it.

• Will there be one large repository, or will the projects be separated into different repositories (e.g., like BlazorExtensions)?

For you as the administrators to decide.

• When should a component be part of the community components instead of the core project?

Bit of a grey area, I think. A viable path could be, in my opinion that a components gets released as a community effort and if it becomes broadly used/popular and is all grown up in a sense of code and tests, it can perhaps 'promote' and become part of the core offering at a certain point.

• Will this be entirely community-driven, or will you also be available for regular discussions and coordination?

As far as we are concerned it will be entirely community driven, yes. But we are happy to advise and act as sparring partners of course.

As said, Denis and I just can't be involved in mode code, maintenance, issue triaging, issue solving, etc. Also, we need to guard the foundation and not let the core package become too big and contain everything everyone wants/asks for.

[PascalVorwerk]

This sounds like an amazing opportunity to learn many new things! I would be interested. Should we open up another channel like a discord channel/server to discuss things like scopes, vision of the extensions? When do we accept new components, what are the criteria etc?

[vnbaaij]

I want to see if I can get you and others added to the GH org already crated. Once that is done, you can organize it in any way you (as a group) see fit.

[oneolddev]

@vnbaaij

I've been wondering about the status of the extensions project 😄.

Like @MarvinKlein1508, I also have questions. For example, addition of other dependencies. I've wrapped some Javascript libraries in some of my custom components. Should those be considered candidates? A lot of things to be discussed.

In any case, I would be happy to assist where I can. Thanks for considering me.

[vnbaaij]

Like @MarvinKlein1508, I also have questions. For example, addition of other dependencies. I've wrapped some Javascript libraries in some of my custom components. Should those be considered candidates? A lot of things to be discussed.

Like I said, it is entirely up to you (as the group of maintainers of the extensions) to define what can be included and what not (although external dependencies might complicate promotion into the core because of licensing differences/issues). We don't care. Well actually, we do care :), but it is not up to us to decide about that. We will adhere to a strict separation of responsibilities.

[JeremyJ78]

This is really, really interesting...
It could be a real honor to participate at the creation of an extension library for FluentUI...

But I have two questions :

• It could be not impossible that Community Fluent Extensions Components will have less performances than the Fluent Library...
  Because, sometimes, we know better other technologies like UWP, WinUI, WPF... And when we convert some components, some lacks of knownledge of the html, javascript things avoid good performances...
  (For example, if I take TileGrid I created as example, maybe some javascript | c# code could be optimized and extended)

So how to handle such cases ?

• Does the components have the right to begin with Fluent prefix ? (Like FluentColorPicker ? FluentTileGrid ? FluentXXX ?)

[MarvinKlein1508]

When I understand the mentioned discussions correctly then all community components should start with FluentCx. Once they get promoted to the official component they might be changed to just the Fluent prefix.

Of course the community components will vary from the official components. It's up for the mangers of the organization to maintain the stuff and set the defaults for contributing.

[oneolddev]

We are going to need some sort of charter outlining the guidelines of project. For example, I believe all the extension components must as consistent as possible with the look, feel, and functionality of the core Fluent UI web components. These extensions should support the use of design tokens.

I can also see a class of extension components used specifically to support backward compatibility. For example, BreadCrumb. There doesn't appear to be an equivalent V3 Web Component. I do use FluentBreadCrumb in some of my projects. Having a compatible version in the extension library would simplify migration.

Again, these are just my opinions.

[vnbaaij]

Yes, we agreed on FluentCx as a prefix earlier.

[dvoituron]

Yes, I think FluentUI.Blazor.Community namespace and FluentCx prefix are good choice.

To be coherent with a part of our naming conventions (also used by AspNetCore team), this editorconfig should be used.

[PascalVorwerk]

#3671 This example component in the dev 5 is an example that i would love for development purposes.. That opens up the question, does the community library also expose componets to make development easier? Or really only components to be used always 😛

[dvoituron]

This PR contains the same React page content https://react.fluentui.dev/?path=/docs/theme-colors--docs

... But adapted for .NET 😆

[PascalVorwerk]

Heya, any news on this? 😄

[vnbaaij]

Nope. The owner of the repo has not responded to me at all.

Maybe better to create a new organization here on GH yourself? Something like 'Community Toolkit for Fluent UI Blazor' perhaps? For all other things needed you can still go with the things we spoke about in this topic before.

[PascalVorwerk]

Ahh thanks for trying. I would love to do this, but i am really not too experienced in the github space, especially when working with organizations, projects etc. Ofcourse if i have to i will, but maybe someone with more experience on that can open it up and add us. Any of the other people tagged more experienced in this kind of thing?