[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.

[winstonewert]

How does such a service have inherent data flow problems? Especially since the NgbModal service IS built on a component that implements pretty much the same thing as react-bootstrap's Modal.

[Bahamut]

It uses components, it is not built on a component - the goal is for it to be able to manage multiple modals and some situations that are impossible to do right with component-based modals such as reusing a backdrop (I argue that multiple modals is a bad pattern, but it is a high demand user feature). It also allows flexibility into hooking into the lifecycle in the future with knowing when the modal renders, starts or finishes animation, and similarly for when the modal closes.

With component-based modals, you end up with bad APIs for these use cases, as well as less control over your state.

[winstonewert]

I think we are talking about different things.

Yes, if you build a component based api that supports multiple modals, resuing backdrops, lifecycle hooks, that api would suck and be a real pain to build a service version on top of.

A React component should not be trying to do all that, but merely produce the appropriate HTML for a modal dialog. That produced HTML can equally be used to build one-off "are you sure?" dialogs, a modal service, or what have you.