Semantic UI

[SachaG]

Let's discuss adding a set of Semantic UI components to Vulcan.

[SachaG]

Also feel free to add a 👍 if you'd like to see this integration in Vulcan core.

[jwrubel]

👋 I would obviously love to see the process of using a different CSS framework be easier. I spent a lot of time looking at #1823 and #1935 when I was working on my project, and I also spent time looking at https://github.com/nolandg/vulcan-semantic-ui . I was never able to remove the core bootstrap (probably because I was afraid of breaking things I couldn't fix).

I think the first step here is to decide how to abstract the functionality from presentation. The process described in #1823 seems good - if you can bring it to the step where Vulcan.Button and Bootstrap.Button are separate, I'll very gladly volunteer to build the Semantic UI Presentation layer. It's the least I can do for all of the speed that Vulcan gave me in bringing https://softstuff.tools to life.

[SachaG]

Actually now the Bootstrap layer is completely separate from Vulcan core and isolated in the vulcan-ui-bootstrap package.

So I don't think there should be anything preventing us from having a Semantic package. It's just a matter of recreating each of these components with Semantic (and adding any other you might need).

[eric-burel]

Hi, the hardest part is to avoid code duplication. Right now, vulcan:material-ui is hard to maintain because it contains too much logic, so I end up maintaining my own fork instead :/

I've had a first experiment with the DataTable, by splitting it into Layout components. The gotchas are:

• removing as much logic as possible from the components can be tricky. You can see my first try on the DataTable, some of the layout components I created could have a better API.
• it creates tons of components, whose names become part of the API and cannot be changed easily later easily (otherwise it breaks 3rd party UI libs).
• librairies does not always have the same level of nesting. Eg sometimes you need additional components to maintain the layout. See tables for example you might have different system than body row and cell depending on the framework.
• beware of the props of these presentational components. They must have the same props as there parents to handle tricky use cases (eg if the dev want to compute some styling based on the data)
• APIs between UI libs are very different. You won't manage to have a common Button API for example, you really have to rewrite all UI components if you want to switch from one framework to another.

Writing additional UI package is a good way to detect and solve this, you will immediately see whether your new implementation contains too much logic. Material UI lib have proven that its perfectly doable. However that mean some more work on the core too.

Also I think there are still references to Bootstrap class names in the default implementation of the core. We could get rid of this too, and limit the core implementation to div and span with no classNames.

Concerning Semantic UI, I am not a big fan, the React version is voluntarily limited to a direct translation of the CSS version, which is not always possible/idiomatic/optimal. They tend to quickly close Github issues. I'd bet on Bootstrap, Material UI and Ant UI instead, that are more React friendly.

[SachaG]

APIs between UI libs are very different. You won't manage to have a common Button API for example, you really have to rewrite all UI components if you want to switch from one framework to another.

Really? I guess I would need to really try using a different UI library to know, but my goal was indeed that you could switch from Bootstrap to Material just by switching out a package. Of course if you start relying heavily on more advanced features of a specific UI library it won't be possible anymore, but I was hoping that it'd work at least for all Vulcan core components so people can pick the starting point they prefer.

[eric-burel]

I think your goal is perfectly achievable for Core components indeed, sorry I was unclear. I just mean that the common API will be necessarily limited, and sometimes not that trivial to define.

Often it's stuff about colors, eg they have different notations/systems to handle palettes and theming, so it's not that easy to handle the related props. They can have a default behaviour for buttons and links, and so on. Modal is a good example of how 3 frameworks will have 3 totally different implementations.

But again vulcan:material-ui has proven this to be doable, it's just that we need a bit of refactoring and improvements to extend this to multiple UI frameworks and keep things clean and maintainable.

Edit: sorry I closed by mistake

[alirezamirsepassi]

Please also provide core components such as datatables, available without having any framework installed. I was struggling for days with adding datatable to my semantic UI designed application, and the error was not providing any information that I should use Vulcan bootstrap UI for the datatable to work properly!

[SachaG]

Please also provide core components such as datatables, available without having any framework installed.

Because Vulcan generates forms for you and also provides premade components such as modal windows, buttons, etc. it's sadly not possible to make it work without a UI library of some kind.