Hacker News new | ask | show | jobs
by Bahamut 3564 days ago
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.
1 comments

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

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.