[Bahamut]

I think ultimately ng-bootstrap* (https://ng-bootstrap.github.io/) will be better, but I'm biased. API signature looks much better than shoehorning everything into components that don't belong there - we have a lot of work to go though, so it currently is still a work in progress.

* I am a part of the UI Bootstrap/ng-bootstrap team - we worked on ng-bootstrap starting back in last August/September and have the benefit of two of our team members currently working on the Angular team.

[winstonewert]

Could you elaborate on what you mean by "shoehorning everything into components that don't belong there"?

[Bahamut]

There seems to be a lot of advocacy for tossing everything into the component tree in the React ecosystem - recently I got linked to a snide remark by Ryan Florence on Twitter implicitly arguing for putting everything in the component tree, including constructs that should have a better separation such as routing (which the tweet appeared to be a reference to).

Some services don't belong in JSX though - this is why you have the idea of stores in Flux/Redux/etc. Some data doesn't make sense to couple to the component hierarchy - doing so makes it very easy to create dependencies on the component tree, which decreases modularity, as well as has perf ramifications by increasing the DOM elements that get rendered unnecessarily by React. Some examples are data models, routing, and interactions with non-element DOM api (window.location, XHR, etc.). This also has a side-effect of increasing difficulty of testing what generally should be vanilla constructs not tied to various frameworks/libraries unnecessarily.

[winstonewert]

I can see the objection to putting routing information (and similar) in the component tree.

But you were talking about bootstrap components which obviously do belong in the component tree, so I'm confused by your response.

[Bahamut]

Not everything is a component - as I pointed out in another response below, a modal is one clear example where you want an imperative API.

[unknowingone]

From a purely pragmatic point of view, I can say that I write very little code when using react-bootstrap, can create screens quickly and the results look good. Not sure how much simpler of an API you can get. But to each their own. +1 to choice.

[Bahamut]

It's not about just simple - it's about making the right architectural choices that don't come back to bite you due to the need to make a change that brings down a house of cards from a library perspective.

ng-bootstrap avoids problematic apis such as component-based modals, and makes use of the much more natural service-based approach to allow developers maximum flexibility. If a developer prefers a component-based modal, a developer can very easily build a lightweight component on top of it. However, having poor design built into such a third party library that is meant to be used for a large variety of cases is a terrible experience for developers, speaking as a consumer and as a library maintainer.

Extensibility is the key here, and we maximize for that while keeping the library as small as possible - bloat is bad, and that shouldn't be the default in general.

[winstonewert]

I don't think that your service based model is more extensible. Yes, I could build a component based version on top of the service based version. But I can also build a service based version on top of the component based version.

In fact from a peek at the source, the NgbModal class is built on a NgbModalWindow class which acts much like react-bootstrap's modal. So, ng-bootstrap builds the service based version on a component based version. If either library can be accused of bloat it ng-bootstrap for including the serviced based version when I might just want to use the NgbModalWindow directly. (Its not in the documentation, so I wouldn't actually use NgbModalWidnow directly in practice, even if I'd want to.)

Now, I've drunk the react cool-aid, so take my opionion with salt. But in my assesment while modals can be somewhat awkward in the declarative style, they aren't awkward enough to make me break my rule of avoiding imperative apis.

[Bahamut]

A service based one on top of a component based one has inherent data flow problems. ng-bootstrap, following in the footsteps of UI Bootstrap, takes a promise-based approach because we believe this is clearly the best API pattern out there for dealing with modals from experience working with users' needs. An evented model is extremely cumbersome/awkward, and any component-based model must go that route to signal when it opens/closes. A promise best describes this situation.

[unknowingone]

Compare for yourself:

https://react-bootstrap.github.io/components.html#btn-dropdo... (click on show code)

vs

https://ng-bootstrap.github.io/#/components/dropdown (click on <>)

[winstonewert]

I don't understand the distinction you are trying to draw. Both examples seem to put the same configuration in the component tree.