Hacker News Reader

Comment by chrisballinger | Hacker News Reader

I expected angular.io to be a flashy example Angular 2 SPA and was disappointed when I realized it was just a regular old static HTML website. I guess most of the content is more suited for a static site. At least the search bar on the docs page looks like it has some Angular going on. Also it would be neat if the docs had dynamic examples instead of screenshots.

View on HN

It actually is an Angular 1 app, for a very simple reason: when the docs site was started, Angular2 wasn't fully usable yet! There is an effort underway to rewrite it in Angular2, so it will be eventually.

May I ask if you have seen yesterday's post about Cx and what do you think about it?

Cx documentation is written using Cx and it offers plenty of interactive examples and code snippets.

https://cx.codaxy.com/docs/widgets/grids

Disclaimer: I'm the author of Cx.

We're all going to get a couple of nights sleep, but that project is in progress and should be out soon. We're making sure it shows off the best of ng2.

Same. I think it would be a nice statement to make if angular.io itself was an Angular app that was a joy to use.

But can it compete with this?

https://react-bootstrap.github.io/components.html

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Compare for yourself:

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

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

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

Opening that link in a new tab beach-balled Firefox for a few seconds. Woof.

Yeah it takes 2 seconds to render on my laptop. It's showing docs and examples of every component on a single page. It's convenient to use as a reference when programming. You probably wouldn't code your app like that.

I'm currently developing a mobile app using React (web, not native). And I'm using the regular bootstrap. What advantage does react-bootstrap have? I seriously don't want to learn a new framework.

Reply on news.ycombinator.com