Angular 9.0
blog.angular.io
blog.angular.io
This was a fast release cycle. It was back in November 2019 we were talking about 3.7, and now it's in.
I'm not even thinking about Ivy. But it's nice to have all the nice comforts of typescript ready and working out of the box. (I mainly work in React, but dabble with angular/vue to stay up to date)
And what a smooth update process (abbreviated):
ng update @angular/cli @angular/core
** Executing migrations of package '@angular/cli' **
** Executing migrations of package '@angular/core' **
Your project has been updated to Angular version 9!
For more info, please see: https://v9.angular.io/guide/updating-to-version-9My app is a big stack of workaround stuff that might break anytime. Because that is how angular work. Some stuff work in a context and doesn't in an other. Nobody's know why ! They have so much issue on Github that they need a bot to close them after a while. They hope the bug disappear by himself ?
Join us, you’ll enjoy the ride!
Did you try to actually upgrade the react version? Lots and lots of breaking changes in that time, some really major ones along the way. Especially when upgrading react also forced one to change router etc.
An Angular 2+ app built in 2016 (when Angular 2 came out) wouldn't build anymore.
An Angular 1 app didn't even need a build step, so that would probably still work fine.
In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes? Because they definitely haven't. That ecosystem has also changed recommended patterns countless times. They just choose to leave a lot of the old implementation options around if they can while Angular as a frameworks tends to be more opinionated.
Same goes for any library or framework across major versions...
Nobody claimed that stuff which has been built and never touched again stops working.
> In 2016 React was on version 14. Are you telling me that from version 14 to 16.12 React has had ZERO breaking changes?
No, I'm not saying that. If they had zero breaking changes, I would have said exactly that, it would be remarkable.
Nevertheless, there have been very few breaking changes in that timeframe[1] and they are highly unlikely to affect if you're doing ordinary stuff.
[1] https://github.com/facebook/react/blob/master/CHANGELOG.md
> Because they definitely haven't. That ecosystem has also changed recommended patterns countless times.
You can just ignore the "ecosystem". You don't need it. React pretty much only does one thing. It doesn't impose an architecture on you. If you want to go all-in on the ecosystem, maybe it's as bad or worse than Angular. That's besides my point.
> Same goes for any library or framework across major versions...
No it doesn't. Some or even most people working with Javascript are completely out of touch with software engineering practices outside of the web bubble. Breaking changes are supposed to be avoided at great cost. Of course there's no real incentive for that if you're a random person pushing something to npm, or if you're Google and your business model is selling users instead of software.
So no, I didn't enjoy the ride, at all.
Well-managed react is incomparable in power. Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
Unfounded opinion.
> Try to make a library like react-three-fiber using Angular, in less than 500lines of code.
react-three-fiber is much bigger than 500 lines of code.
And no, the initial implementation which was just as powerful (but lacked typescript typing) was mostly 2 files of 250 lines of code each. Look it up.
I am waiting for the angular or vue counterparts. And also the angular and vue equivalents of react native.
Based on personal usage of React, it's no easier than angular or any JS based framework like Vue (which in my view more sensible than react). You add state management, templates, router and 1000's of npm packages to do anything simple and react soon becomes an unmaintainable nightmare with emany vulnerabilities if you do not upgrade. An app is not just simple react but many of the npm packages (although it's true in general for JavaScript eco-system which is by default is insecure and maintenance nightmare unless there is an extra amount of work done to secure it).
Angular at least provide a decent complete single framework to work with and a unified documentation, there are issues with it, but react is same when you need any reasonable size app from it.
React gives you an easy start with false sense that it's easy, than becomes just too convoluted and complicated with the addition of different components as soon as app starts growing. Maintaining and upgrading apps based on react is very difficult as one version to another it introduces breaking changes. Angular had similar thing from angularjs to angular 2, but slowly they made it much better but letting compiler do more work.
Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
I am still waiting for a simpler way of developing web apps, elm looked very nice, but it is still far from ready for use in the same way as Angular or react yet.
It feels cleaner and more solid.
I mean I hear what you're saying, but Angular is an opinionated framework whereas React is not, and many people end up reinventing the wheel (or an application framework) in the process. There is value in being opinionated.
Yes there is value in being opinionated, but it is less risky to decorrelate the opinion from the foundation. There are opinionated frameworks built on top of react and it is very nice like this. But react itself should not be opinionated.
The team that eventually took it over and grew around it recognized it had some problems scaling and being used for large applications. They knew they couldn’t just change angular 1 to be what it needs to be, so they made a big switch. They put in patterns that benefit large apps, typescript, observables, the choice of two way binding or one way binding, better DI system.
Everyone says react isn’t opinionated, and for developing an enterprise app that just sounds like a nightmare.
ng update is ridiculously easy, and the automatic code rewriting is generally sensible and easy to follow. When there are breaking changes, Angular takes care of the modifications for you. Generally I've felt like those changes resulted in a better expressed codebase (eg RxJS syntax improved massively from 5 to 6, lazy loaded routes are expressed with arrow functions now, etc).
I assumed the React community was also migrating versions with codemods, but maybe React does not introduce any breaking changes?
This is, at the very best, very debatable.
In my experience, it's the very opposite. Angular gives you very solid foundations as it's a proper framework that ships everything you need to build scalable apps. So you start from something small, and as you grow you know you can do so without rethinking the foundations of the app, as they are provided by the framework, which is Google guys, which means most likely people with a lot more experience than the average front end dev.
On the contrary, react leaves basic choices (the bricks you mentioned) to the user. While freedom can be good, it also implies that errors will be made, so you are a lot more likely to build on shaky foundations.
Choice to pick the best of breed solution to each smaller problem within the context of building an enterprise grade web application is at the heart of React. I get to look at all published routers and choose the one with the most intuitive API to me: I get to look at bundle sizes, and consider trade-offs.
Instead of spending all my time analyzing different open source packages for every single thing you do, you just have access to a first class supported solution.
IMO, lots of the react ecosystem is built on engineers trying to show off. They get fancy coming up with a solution, writing a unique library, and there’s no reason for this. Everyone likes to think their code is unique and special and great, but it’s not. We don’t need to reinvent the wheel all the time. So many of these apps are going to need to be rewritten in a couple years because of how poorly architected they are. That’s not a problem of react, but it’s a problem of react devs who take a small view library then build a framework on top of it.
I wouldn't characterize my time in React spent "all day comparing open source packages" -- if that's what you think web application development on React looks like on a day-to-day basis, you haven't done much on it.
To be clear, I do not intend to speak negatively about Angular. Some people love the provided structure. It's also not for some other people. This is okay. Different things make different developers happy. I wasn't generally describing all people's sentiment: that would be insane, both frameworks have huge backing. If you'd like to understand more about how some people view the framework as inflexible, and you're open to that perspective, I'm glad to shine some light on it.
A lot of comments state angular is inflexible and opinionated, but come from people who haven’t used the framework. They think your forced to do a lot of things where angular gives you choice.
I haven’t done much react development, but my significant other has and multiple members of my team have as well, and I’ve heard them discuss how when you need to find a package to pull in it’s a decision that involves searching and weighing the pros and cons much more then for angular.
I don’t hate react at all and totally understand its pros and how I think it’s a net positive on the web development landscape. It’s more that this site is extremely react focused and biased, and the US dev community is also that way. So angular gets called out as being something stupid to use that’s cumbersome, slow and big, but that’s just simply not the case. Example of angular app being smaller and faster then comparable react: https://www.freecodecamp.org/news/a-real-world-comparison-of.... I know these comparisons are silly so I’m not putting much thought into it, just one anecdote.
Both are great libraries/frameworks with great ecosystem of developers, we all need to stop flaming each other and see the progress each community is making. It’s not a winner take all type deal, there’s plenty of room for both.
This has been solved by create-react-app. I'm working on a 10K+ LOC app now, and the only significant dependencies that aren't part of create-react-app or its docs are d3 and date-fns, which don't belong in a framework anyway.
This is just a bad idea: https://angular.io/guide/template-syntax Without writing the tooling to debug it, to this day there is not said tooling.
https://juristr.com/blog/2019/09/debugging-angular-ivy-conso...
You don't actually have to do that. React just turns your data into DOM elements, most of the time it's a simple transformation.
Otherwise, how you architect your application is up to you. You don't need to overcomplicate things by following the latest trends, you don't need a ton of dependencies to do simple things. You don't need templates at all.
Angular is complicated by default. It makes design decisions for you that you probably wouldn't have made, and then sometimes it reverts those decisions, making you clean up the mess. React code very rarely breaks.
> Ivy tree shaking compiler will give a fight to upcoming compiler framework like svelte and keep the size smaller and may be in some cases much smaller than react app bundles, will wait for the benchmarks and size comparisons.
Angular bundles are huge by default, it has a long way to go. Tree shaking already works with React, you just need to set your build up that way. Also, don't assume that a compiler will make your build smaller, it may well inline a lot of stuff and end up larger.
Unless it's doing unsafe or nonstandard stuff in the first place, like idk, cross-domain requests or weird stuff with iframes or whatever it was Google tried to do when it added an extension that tried to do preloading and stuff like that.
I have a backendService that use the httpClient; it's a wrapper that automate stuff to make API request. I guess it's pretty common. I have a provider for APP_INITIALIZER. It can use the HttpClient but not the backendService. The backendService work everywhere else of course.
I have personally witnessed companies take guys who have been slapping together "apps" in jQuery / .NET for the past 10 years and tell them "it's time to make the stack modern" and "we're going with Angular because we're a Microsoft house".
Things go very bad very quickly.
If you don't take the time to understand the Architecture behind scalable modern web applications you're going to have a bad time.
Anyone can slap together a quick and dirty app with Angular or React - not everyone can scale one correctly with thought given to the architecture behind these applications.
Neither of those is Angular-specific. In fact, of those you mentioned jQuery is the library with the unusual, idiosyncratic concepts.
I don't think Angular is a bad choice across the board, but you need to weigh this heavily when deciding to use it.
Is ms invested in Angular?
It's a Google project, isn't it? Is it first-party in dot.net? I though that was Blazor?
Microsoft also supported Angular early on as it was one of the largest early adopters driving folks to Typescript.
Before Angular, those developers would probably have chosen Knockout.js instead.
Yet I agree, a lot of things in my project is wrong and maybe blaming the framework for the mess is too easy. But I really do not enjoy working with Angular. Also, learning to use RxJS was a painful experience full of frustration.
By all means, upvote criticism that is properly argued and backed up with evidence. But upvoting these kinds of comments is the equivalent of posting anti-vaccination memes on Facebook.
I've been working with Angular2+ for 3 years and I haven't met any bug.
Know the concepts, apply them and you'll have an easy trip.
Translation: It's a framework that does less.
Give me a break, this isn't true for any code in existence.
There is software that's incredibly solid.
What I don't like is the verbosity and boilerplate... here's 2 examples:
- Routing boilerplate is convoluted and time consuming. I think Nuxt.js has a much nicer implementation of SPA routing, where the filesystem is used to map the routes.
- Angular modules are verbose, redundant and don't even truely encapsulate dependencies anyway. You can easily create implicit dependencies by relying on services instantiated in higher level modules.... which is bad
I love using Typescript though!
From what I understand of React, you need to pick and chose the libraries (and versions of those libraries!) to use for your app, and then keep the versions of all the different libraries up-to-date and in sync with each other. Sounds like a maintenance nightmare.
The other reason is the first class TypeScript and RxJS support.
I've seen people tout this as a benefit for certain ecosystems for years and years and years, and I think it's a big bag of crap. Maybe if you are ultra talented and ultra disciplined, it's possible to stay on the ball and make things work when you are gluing together disparate pieces and shaving an untold herd of yaks.
But for mere mortals, having sensible defaults and pieces that were designed and built together is wildly more productive.
I was more amenable to the libraries-not-frameworks argument a decade or two ago, when release cycles were once or twice a year, libraries were mostly independent, and granularity was much coarser. Now it's just too goddamn much work to keep things sane. I do not have time to dedicate a day a week to troubleshooting why updating package X has pulled a new dependency on library Y, which is incompatible with library Z.
Not really, since by design React doesn't care. You can use a years-old version of React Router without any problems.
Is that minified and gzipped?
That being said, 973kb seems like large-sized rather than mid-sized to me.
It reminds me of a great hack where game developers used to hide a large memory allocation early in the game development process and when they ran into memory constraints towards launch they'd just comment out the line and instantly save the day. Artificially constraining the memory caused intermediate development to be more frugal and ultimately allowed them to get where they needed to be by the end of it.
We also worked on making the runtime tree-shakable, so in your final bundle you can get only what you use.
Additionally, we made sure the code we generate compresses well with popular algorithms.
https://krausest.github.io/js-framework-benchmark/current.ht...
I know micro benchmarks don't tell the whole story, but when you consistently wind up on the slow end it's not a good look.
that metric is slower in general because libs with simple reconciliation strategies will tend to do work for every row between the two swapped ones (2,998).
The ecosystem is bigger and there are more devs available.
That said -- performance characteristics like this are rarely interesting to me. The vast majority of "performance issues" I've encountered have to do with high-level architecture and/or network issues. I've never given up on a framework because it couldn't swap two DOM nodes fast enough.
react has always been approx where it is now. but there are a lot more faster libs in the table.
Didn't know that. What I thought I knew is based on years of breathless claims about React's great performance. This is eye opening. Even Angular 8 does better in these benchmarks.
I also wonder if batteries care about elegance. Not really they don't. If one makes the highly likely assumption that these micro benchmarks are a measure of efficiency then it's actually difficult to do worse than React regarding battery life, heat, etc.
Very interesting.
I don't use Twitter, so can't comment.
Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:
Also, note that we have a new "Style Guide" docs page which specifically recommends patterns that we feel will lead to simpler code, like the "ducks" structure for single-file Redux logic:
https://redux.js.org/style-guide/style-guide
Finally, we're currently working on a major rewrite of the Redux core docs, with the goals of updating them for today's target audience and teaching easier-to-use patterns:
https://github.com/reduxjs/redux/issues/3592
(and by "we" I basically mean "me", since I'm not getting a lot of help with this effort so far.)
I'll also point out that while Context is a great tool for making data available to a nested subtree of components, it has major limitations in terms of processing frequent updates. We tried to use it internally in React-Redux v6, and it just wasn't sufficiently fast enough, which is why we had to rewrite the internals again in v7 to use direct subscriptions instead. So, very useful, but not a replacement for Redux.
Thank you for your work on Redux - I think it's fantastic!
Lots of hate in this thread, but React/Redux are great, even if that somehow makes me an imposter or a hipster or whatever the tools I use somehow say about me.
I obviously didn't _create_ Redux, but I'll take a decent amount of credit for helping keep it relevant over the last few years (docs work, blog posts, answering questions, React-Redux updates, Redux Toolkit).
I'll say up front that it's definitely not as "necessary" as it was early on and that there's lots of other great alternatives out there, but yeah, I don't get the recurring waves of "I hate Redux" that seem to pop up on Twitter every few months.
FWIW, I talked about some Redux usage stats and where it fits in compared to other options in my "State of Redux" talk at Reactathon last year:
https://blog.isquaredsoftware.com/2019/03/presentation-state...
Looks like I should get to do an updated version of that talk later this year.
This is the cost when app architecture gets delegated to your developers over a high quality central solution, the quality is as good as your developers.
Juniors new to React are unlikely to do so, IME (as a semi-new-to-React not-junior working on a team with new-to-React junior-ish devs -- by experience; there isn't a formal junior/not-junior distinction on our team.)
OTOH, if you do things you really shouldn't do in React, while they won't all be flagged, there's a very high probability it will result in at least related warnings pointing to it in the devtools console, so that's something.
I'm not saying I personally agree with the decision, but I could see how management might conclude to chose Angular with that rationale.
All in all you shouldn’t worry too much about employability if you pick and stick with something popular. Check your local job-market and stop worrying about what’s hipster cool on HN. There hasn’t been a single Rust or Go job listing in my entire region of Denmark for an entire year, mean while there are currently around 150 PHP positions open right now.
Is it just the pairing of React / Redux you find unappealing?
Your feedback is disappointingly vague but you seem passionate about it so I assume there’s something deeper here.
Edit typo
Meanwhile, for Angular, I keep constantly going back to the documentation, trying to remember all the small details about templating, binding, decorators, modules, dependency injection, etc...
I stand by my point, I am yet to find a use case where some form of react is not the best solution. Whether it is server side rendered, a single page app, or statically rendered.
The only criticism I hear about react boil down to people complaining about bad practices that are not linked to react, but merely conflated with it, like not caring about bundle size, messing architecture or other aspects that are orthogonal.
That's not true, you can use JSX with Vue, we do use that for one of our clients and it hasn't raised issues whatsoever
Render functions returning JSX is the key brilliant idea invented by react and the fact that vue adopted it just proves the point even more:
React or the ideas at the core of react are not the mistake of the last decade but the blessing of the last decade for web development (and more).
It will not, because Vue has a better integration with the data source (Vuex) and a better integration with the routing (Vue Router)
I mean, I agree that React is an awesome framework implemented upon great design ideas (pure functions and plain JS templates), but it has its shortcomings, that frankly make me still prefer Vue to React (mainly Redux and the router)
But whatever floats you boat really, the point is that the nice part of vue are inspired by react anyway. I wish the two community merged, to be honest, I see no point in dividing for such small differences.
You specifically argued against that, your arguments seem to be highly religious in nature.
I don't know how many years you've worked in the industry but if you think React will be the dominant way of building apps for the next ten years, I have some Adobe Flash developers who I'm sure would like to say a few words.
Seriously though, JSX and TypeScript are nothing new. Both were part of ActionScript 3, a big language backed by a powerful company (Adobe). 15 years later, nobody even remembers it existed. How am I still making a comfortable living coding today? By not getting too attached to any language or framework... they are all just tools in the end.
So let the young ones be, time will eventually teach them those lessons, sooner than they think.
I remember E4X and Flex but not a JSX like syntax.
My arguments are not religious but based on facts, I can share my PhD thesis from 2016 about user interface specification languages, that includes a comparison of more than 20 different approaches including react.
Flash was always a proprietary platform and only fools would have bet their whole career on it back then. The situation of the ideas behind react, and browsers as a platform are very different.
I’m not betting my career on it though (I’m a CTO in a company which Is not centered around web stuff) but I do believe that these ideas will leave an impact in the industry, and this belief is backed by specifically studying this topic for 4years, plus my 15years in the industry.
My job is to enforce some semblance of sanity between very smart and clever engineers without heavily impacting their ability to deliver. My job entails much cat-herding, setting norms, and maintaining expectations.
Every day I thank the gods we went with Angular. It has saved us countless times, every refactor is a joy, every upgrade is painless, every component is easily shared.
I don't have to constantly worry about XSS, I don't have to explain how I want things structured (because the build fails if they don't structure it right), and I don't have to worry that if someone leaves, no one will know how to pick up and modify their project.
Do developers hate it? Absolutely! They want to get work done fast and pump out cool, clever, smart work! They see Angular as a hinderance to the objective of "doing" because now they need to know about all these damn opinions that aren't their own. Angular isn't for them, it's for everyone else.
By contrast, React enables selfish coding, which while totally okay when you have a few people and clear lines of ownership, does not scale well without strictly defined responsibilities and amazing cultural levels of synchronous decision-making.
Nail meet hammer. Seriously though, what why you need a JS framework for static pages? What if your backend is in Go? What if you're doing heavy duty numerical analysis? What if your users want a Wordpress-like site? What if your team uses Rails or Drupal to quickly build sites?
You're saying React is better at everything?
https://en.wikipedia.org/wiki/Tears_in_rain_monologue#Tannh%...
Hopefully you're not disappointed :)
[1] https://en.wikipedia.org/wiki/The_Three_Stigmata_of_Palmer_E...
Of course, those are lightweight / 'native' (to react) alternatives to redux / state management; last time I used it there were some really neat (theoretical) advantages, such as a browser addon where you could do time traveling debugging (replay individual events) or push the state and all state changes into a support ticket for reproducibility. Purely theoretical though, and at the time using Redux added a lot of mental and labor overhead, especially when using it to manage forms. (personally, I think form data should never be part of a global state; it should be limited to a component that manages the data itself and does not leak it elsewhere. But, it depends on the situation, as always)
That react-three-fiber project is cool, but engineering is not about you can do, it's about finding the best solution for a given set of requirements, and 95% of web apps don't need that kind of functionality - it's just unnecessary over-engineering at a huge overhead cost.
React devs love to talk about one-way-data flow and Flux state management. They forget state doesn't come from the client, it comes from the server. Why not carry this one-way-data-flow model all the way back to the database, which is where your state actually originates?
I fully agree, and this is why I can’t understand why in 2020, some people still don’t understand that react/SPA and node backend for server side rendering are the best solution.
With react and server-side rendering you code your front end only once, of course. And the same codebase can be rendered on the server or on the client transparently. Same JS libraries can be used in the server, in the browser, in mobile apps with react native.
There is just the API on one side, and the frontend on the other side. Where the frontend is rendered does not matter.
Having used both Angular (since 1.0) and React (only recently), it's obvious why React is more popular. Any decent engineer can be productive in React within a day since the concepts are so intuitive and simple. With Angular, if you don't really know how things work, you are going to struggle a lot for a while.
While i can't speak for the rendering performance, the design itself is definitely elegant and not built for "code monkeys" but real engineering productivity
I think that just by using Hooks and Contexts you can get a lot done in a predictable way without adding too much complexity. With typescript and a proper IDE you get also wonderful type-checking and refactoring capabilities.
I used AngularJs (1.x) a lot before and in comparison it was both more complex and full of unexpected behaviors.
I have less experience with Angular (2+), but I found it much more complex and in some parts over engineered.
You don't have to create actions or constants anymore, you just create your reducer functions and selectors, then use hooks to select and dispatch in your components.
Never got why people took up a completely different paradigm just because they couldn't figure out how to reduce their boilerplate...
React can be that other half...
What do you even mean?
Redux was a simple and elegant implementation of the unidirectional data flow (aka the Flux pattern). It came out during the time when the state of the art was Angular 1.x (aka AngularJS)'s two-way data binding, requiring a lot of dirty checking. Redux might or might not (the story is moot) have been influenced by Elm, which has exactly the same concept of actions, state modifications in response to actions, and re-renders in response to state modifications; all as pure functions; and Elm developers are finding this approach enjoyable and predictable. But even Elm aside, the pattern that redux is using, i.e. communicating via messages (actions) and subscribing to state changes in connected components, is a variation on the age-old, battle-tested event sourcing and pub/sub. What's so bad about that?
Pretty cool.
Angular was built specifically around avoiding an entirely different problem that the heavily debated issue here of overengineering: Multiple teams that build out complicated and feature laden systems in parallel need to make concessions to allow interoperability.
If your organization is culturally flat, Angular prevents the core of your application from diverging in unmaintainable ways.
Also it's worth nothing that React and Vue scale. They work as well for small, scrappy projects as they do for large enterprise ones. I wouldn't say the same for Angular.
Regardless of the underlying philosophies, the choice between React, Vue and Angular is a very real one businesses have to make everyday, so it makes sense to compare them.
Supporting a large 1.x codebase right now, and would love to start incrementally moving to angular.
* Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework.
* evaluate if Angular really is the right choice to upgrade to * if it is, do not mix the code in one repo. Use two repos.
* Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app
* to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc
* how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps.
* update your deployment and testing strategies to account for two apps going out instead of one.
* we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems.
* get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over.
* allocate x% of Dev time to the transition.
* agree on a date for each route and for the full transition so work can be prioritized.
I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.
I maintain a sizable 1.x codebase and am deciding what to move to, since 1.x is dead next year. I just don’t see a good reason to go to 2+. It’s a different framework. All of the UI libraries we built upon (ng-grid, angular-ui) are either gone or different enough that we will have to redo all of our code no matter what. If I have to switch frameworks anyway, I want to go with something simpler (no custom module nonsense, no annotations, no hierarchical dependency injectors, hell, no classes!) with a healthy ecosystem.
React with hooks, bootstrapped with CRA, is the clear winner for me. It’s just so much more straightforward to reason about, and way faster to build things with too. I made a toy app in Angular a year ago to check it out, and had a hell of a time even getting the simple data model working right. With React, day two had me already wiring up a dashboard with charted details that responded to a calendar widget I had customized to show QoS at a glance. I was looking at Vue too before I read up on react hooks, but once I saw functional components everywhere I was...erm...hooked. Sorry.
Now if only I can convince them to let me use ClojureScript...
We’ve had a bunch of long-standing state management bugs and performance issues too ($watches, $watches everywhere, nor any prop’s in sync) that we built a lot of cruft around trying to fix, mostly due to two-way binding and our weird use case. Some were unfixable due to the framework and others due to bad early decisions. But This Time!!
It will definitely be fun to rewrite. The app is so much like a web-based dumb terminal that a view-layer library like React was probably always a better fit for us, had we known about it when we started the project. Plus the JS ecosystem is a lot nicer now: arg destructuring and VS Code’s intellisense thanks to es6 imports are both big productivity wins. Also, not having to maintain a gulpfile is its own blessing.
The more I can compose with pure functions that operate on immutable data, the happier I am.
Except maybe for modelling/simulating concrete classes of objects (ie, as in Simula, the language).
Proper multiple dispatch (a la common lisp CLOS) seems rare - I'm guessing java/c++ seemed like a sane trade-off for some type safety - but they probably should've stuck to self/smalltalk (for Java) or looked to standard ml/common lisp (c++).
I still don't understand why Javascript got classes, rather than some paint on the prototype system.
Having used React for some years now, I have to say: I wouldn't compare the two. React's atomic ecosystem is perfect if your stack of tools you embed doesn't grow too large.
However as soon as you want the feature set Angular provides out of the box IMHO you're screwed.
Another thing to think about though is how you're currently doing state management. Angular 9 is all about RxJS, and if you're currently managing state without it, your migration will be that much harder.
Personally I wouldn't go for a vanilla JS application, not unless the script / application part of it are minimal.
Management was very happy with how modern the stack felt
Sales came to a halt for 2 years since features came to a halt.
Turns out Angular is freaky hard to do right.
There were definitely Angular-related issues, but they were replacing a lot of "my state machine is out of sync" issues that just scopes and watching mostly solve (except for the prototype inheritence gotcha)
I guess whether or not you'll be productive with Angular depends a lot on your experience and expectations. I come from the C++ world and Angular felt like MFC, so oddly familiar.
I then tried React and it just kind of made sense. Since then from the sidelines I've heard Angular has gotten much better but personally don't see any reason to use anything other than React at this point in time.
I haven't used Svelte at all but it looks very interesting.
React: Write a function that generates a piece of HTML. Use standard event handlers to manage user interactions. Update state via setState methods. Ship it.
The method for passing data to a dialog component is to import a magic constant and inject a data field into it's constructor? It's a completely over-engineered, nonsensical solution for a problem that doesn't even exist in React. There's so much stuff you have to be familiar with in Angular just to build the simplest features.
Take a look at what you have to go through if you want to create a custom component in angular material (that can sit inside a form):
https://material.angular.io/guide/creating-a-custom-form-fie...
Something has gone completely wrong here.
I can only guess that "same team" was a design-centric subteam for Angular while the engineering-centric team worked on the framework/documentation itself, or that Angular Material was under pressure to get implemented before all the best practices were established and by then they were stuck with the API.
And every release .NET just keeps moving closer to the dumb systems. Simple and raw is good, keep the magic away
The amount of complexity is mind boggling.
I mean, look at Flask in Python. Or even Expressjs in Node, why can't Microsoft come up with a simple framework that can run well on the .NET runtime?
I am a huge fan of C#, having used it for Desktop app development.
I would love to have a framework like flask in the .NET ecosystem.
I found it very simple and minimal (again, other than the DI) when learning it.
Flask is self-described as a "micro framework", which makes it simple to start with, but IMHO difficult to grow into something bigger.
I like the balance the ASP.NET Core 3.0 strikes.
dotnet new webapp -o HelloWorldAnd all of this is easy to customize and change.
"Web API" projects are even simpler-- it's just a small handful of files.
Honestly I'd rather develop in vanilla NodeJS where the approach is at least consistent, than in the Express ecosystem where sure your problems may have been solved 1000 different ways already but where none of them really fit what you want to do, and where there are many layers of hidden incompatibility that are going to require you to make adapters for each library anyway.
I am judging from my experience developing applications with 200+ developers across continents. You can write crappy code in Angular as well, but it helps you govern your architecture and your app. If you want modular components that can be reused, go for Angular. For smaller things or landing pages use Vue, React.
My experience.
The mental model for React is much simpler than Angular's.
In React, There are two concepts one needs to understand: Components, and Hooks. JSX too, but as a web dev the HTML-like syntax was already familiar.
In Angular, you need to understand: the binding syntax; Components; Templates; Factories; Modules and Services. And learning bindings also means learning RxJS (which I love as a standalone lib, but is a big cognitive load when coupled with the rest of ng).
Even just comparing the "Fundamentals" page of Angular versus the "Main Concepts" of React (which, isn't exactly the best measure of complexity, of course, but it's A measure), you can see Angular spends 8 of its 10 sub-sections explaining essentially-required concepts, while in React it uses 6 out of 12 sub-sections.
React is much more concise in terms of concepts, and instead just has a bunch of common patterns that are sufficiently approachable and memorable, but most importantly can be "rediscovered"/"derived" on your own, rather than relying on framework-provided "black box" concepts.
And the total load is still in my perspective smaller than Angular. I have never even casually used Vue (I've since switched to gamedev as a profession), so I cannot comment on it, but from a cursory on its docs, it seems like a leaner Angular, which is good.
I've always had gamedev as a goal, and since 2012 participated in "game jams", which are basically make-a-game hackathons; as well as making free web games/prototypes. The industry is very portfolio-focused.
Mostly did webdev as a way of supporting myself until I got a gamedev job (but I like doing webdev too). I currently work at a company that makes corporate/educational games, but am collecting more experience to be more competitive on the actual entertainment industry. Which is a bit more challenging given I'm based in Brazil.
That being said, it's much easier to "switch careers" when you're 22 and it barely started!
My favorite things about React were JSX and FP.
Seems like you've found a good way to have it all.
We understand that we can work on simplifying the mental model of Angular. This is something we're working towards. We're careful with in process though because we want to provide a consistent, backwards compatible development experience.
Not saying one is better than other but in my opinion, entry barrier for React is lower than Angular which may be an important factor for React's popularity.
React seems a bit better, but they don't seem to support older releases at all.
First off, Angular versions post 2.0 are nothing like AngularJS/1.x -> Angular/2.0. They are much more incremental and even the two times the entire renderer has been re-written it was an incredibly gradual process over multiple major versions with seemingly few changes to component and template APIs.
Second, upgrading between Angular versions couldn't be easier thanks to angular schematics. The process takes seconds and for specific rarer exceptions the team maintains this fantastic guide here: https://update.angular.io/
The problem isn't how it's handled or how incremental it is, it's that there are so many upgrades with breaking changes, at least that's what they're communicating to me with their version numbers. There's also the lack of any real LTS versions I mentioned, 18 months doesn't cut it.
> They are much more incremental and even the two times the entire renderer has been re-written
Telling me that they've rewritten major components that frequently isn't exactly convincing me of the stability, its validates my previous belief that it isn't stable enough.
When they've got versions that are supported for 5+ years post release I'd consider it stable. It doesn't matter how good your upgrade guide is when you run into a bug or limitation with the current version and realize that you have to upgrade the entire framework and deal with all the breaking changes to get around it.
Compare that to react where you've got at least 3 years (assuming they follow semver) between breaking changes.
That said, I think, for bigger groups/companies working on a complex product, I can see that Angular ensures a certain level of "architecture" and code organized correctly instead of being coded to each dev's personal style.
But way too complex for single-person apps or for simple SPAs.
All that to say Angular is less popular because it is too complex to learn and use quickly.
Why use anything but Flutter if you choose Dart?
There’s no good or bad. As in any architectural adoption, it should’ve based on your team’s capabilities and support capabilities.
Experience matters too. There are good reasons to use either platform.
No, if it's overengineered.
Conversely, if your web app has one api to call, you may find an opinionated framework to be a rocket engine where only a lawn mower engine is required.
Now, if angular would prove substantially better in terms of performance or maintainability or so, that might've been ok. But they're not. Performance is on par, I find refactorings actually harder because of the heaps of boilerplate angular requires, etc. They invented way too complex solutions to solve problems that either don't exist, or other frameworks solved better.
Would you suggest I go with Angular or React?
It's a fairly complex project, involving user based label designs, data manipulation, etc.
I am API based server and a heavyweight front-end.
Never used it myself, but the guys from Flipboard made this react canvas renderer which might be useful for you: https://github.com/Flipboard/react-canvas
To give just one example. If you want to dynamically import components, in react you just use a dynamic import, since it's just like importing any other js function. Compare this to the angular way and draw your own conclusions: https://angular.io/guide/dynamic-component-loader . Granted, angular may have things that are easier to achieve than react as well. And I don't like the looks of jsx and so on. But my generic experience was that angular was always working against me. It reminded me of my java EE days.
Enterprise Java and .NET shops usually reach out for Angular first.
And I have no intentions to ever advise React with its FP approach with a myriad of endless libraries, to devs that just want to get stuff done.
The learning curve is steep I agree. There does feel like there is a lot of ceremony and boilerplate required for even the more basic "hello world". Also if you are not familiar with RxJS before learning Angular then that is a second learning curve that you need to know too and it is a challenge.
The docs are also very frustrating:
- the API reference is usually just auto-generated with perhaps a single sentence saying "The FooBarDooDad does foo to bar" with zero other content, e.g. https://angular.io/api/core/Query
- the tutorial guides are absolutely huge epic documents, scrolling screen after screen after screen after screen and are far too long and far too convoluted to be useful in my opinion. It feels like they are several entire chapters lifted from a printed book or something, rather than something useful for a developer trying to implement something. E.g. https://angular.io/tutorial/toh-pt6 (and that is just part 6!) I've been doing this for years and I still hate having to go back to those docs.
- the tutorials are all talking about some "Heros" app that I have no idea what it is or what it is doing. I wish they just had examples for the simplest-possible case in stackblitz-widgets that does not need me to know the ins-and-outs of their sample app.
That said, once you are up and running with Angular I have found it is very easy to use, and RxJS is really nice once you get your head around it. Everything works largely as expected, and you can more or less forget about Angular and concentrate on the logic. As far as boilerplate goes, I have found that once you have done the boilerplate once, you just copy-paste from one file to another then do a search-replace for the name etc - takes perhaps 10 seconds etc before you are writing logic.
I would like the Angular team to add some sort of "official" state management feature though in the future. In my view, it is the biggest missing gap in the library and you either have to use NgRX as a separate library, or have to botch a global app state by using either a Service or a convoluted @Input/@Output chain
You are not the only one mentioning this here. Do you believe it's wise to start with learning RxJS before you even approach Angular if you are a VanillaJS/JQuery "dinosaur" looking forward to learn Angular?
No need to master it - probably spend an hour or two on RxJS tutorials & samples to get to know it before jumping in with Angular so you know where the join is between Angular + RxJS.
https://rxjs-dev.firebaseapp.com/api
Reading the guide and pondering the following table helped me understand how other mechanisms in JavaScript work together and relate to each other, and the corner that Observable occupies:
https://rxjs-dev.firebaseapp.com/guide/observable
>Observables are lazy Push collections of multiple values. They fill the missing spot in the following table:
SINGLE MULTIPLE
Pull: Function Iterator
Push: Promise ObservablePopularity is not a useful metric when evaluating frameworks. Community engagement and core team motivation are, and some people may use popularity as a proxy for those measurements.
Does anybody here use Angular for their customer facing websites?
So far I have only deployed Angular once in production for an IoT Dashboard.
It was based on Material Dashboard, it was good enough for the monitoring use case, but it was for on-premises deployment.
It is still early days, and isn't suitable for every use-case, but it could be the answer you're looking for. Continue to write back-end code only. But with the benefits of quick-response front-end app. I'm a total convert (evangelist) who has been increasingly put off by the evolution (devolution?) of front-end development over the past 5-10 years. This could be one way of the mess.
It's the output I'm worried about. The HTML outputted by Angular pre-Ivy is verbose and runs very slow on old browsers (IE9, with polyfills). A customer facing website can be visited by anyone, from a tech savvy Linux user to your grandma which uses Internet Explorer and thinks Facebook is the internet.
I don't want to face the wrath of clients who realize that their website is slow and non-optimized because I'm using Angular.
Anyone have any ideas?
https://stackoverflow.com/questions/60114758/uncaught-syntax...
Seems like it's not adding 'type="text/javascript"' to <script> in index.html. When adding this manually, everything works.
Just FYI if others upgrade and seem to get the same errors.
Modules, however, enforce strict mime type checking. As the comment below suggests, you should make sure your static file hosting serves JavaScript with the correct mime type.
Angular
React
Web Components
https://blog.usejournal.com/web-components-will-replace-your...
Can Web Components pretty much do everything without a framework now? I think Ionic moved to it for example. If we already have our own code for loading and rendering components, using Handlebars templates, what would we need to do to make them into web components instead, or make all of ours compatible with the latest React or Angular?
The specifics for anyone who cares:
When we began our own framework, way before React and Angular, we built our own, kinda “sane” reusable component engine. We called them “tools”. One tool on an element is a component. But you could also add multiple tools on a component, to add or remove behaviors:
https://qbix.com/platform/guide/tools
Basically, we figured it would be easier to just let Templates, HTML, CSS and JS each do what they were intended for.
HTML side
1. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”: bar, ...}’> easily exporting json from php or templating engines, very readable and completely standard (no JSX or custom components). It was just slightly longer to write but provided useful metadata. It used to be called microformats back in the day. Multiple tools can be added on same element this way. The element didnt have to be a div.
2. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of “div” to add a tool on an existing element. We also had a jQuery fn method like $(“foo”).tool(“Streams/chat”, options).activate() .
3. Our users just called var element = Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div />”).tool(...).activate() if jQuery was loaded.
* CSS side*
1. We namespaced our CSS by Modulename_toolname_
2, Some tools took advantage of shared CSS classes defined in the module or a module they depend on
Javascript side
1. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods) and the tool.state would be the options merged over the defaultOptions. It was all customizable and merging was done via a smart Q.extend() function that we tweaked to eg combine Q.Event handlers in the best way.
2. Ways to access tools on an element would include Q.Tool.byId() and element.Q.tools etc. The tool ids would be autogenerated so as to establish a hierarchy of which tool was a parent. Then you could do tools.children([filterName]) and tools.parents() and so on. Traverse faster without touching the DOM.
3. We had Q.activate(container, options) to activate tools within a certain container. Javascript for tools would be loaded on demand, and tools would be added/removed on demand. We had Q.Event.prototype.add(callback, key) take a String key or a Q.Tool, so events would be automatically removed when a tool was removed.
4. You could also do Q.Tool.define([toolName1, toolName2], toolName, constructor, defaultOptions, methods) to have tools require that previously named tools already be activated on the element. This is for composability of tools, something more general than inheritance. Let’s say you have a chatroom and you want to add support for @mentions to it and https://linkscraping.com as you type. So you’d make tools that work in top of Streams/chat.
It seems to me that ANYWAY your user will have to load a Javascript file that defined your web components. And ANYWAY they will have to load javascript on demand. And ANYWAY this javascript may be packed into a single file so you’ll have to actually check whether a variable has been set before loading modules dynamically so you dont want static loading. And ANYWAY your tools may want to use shared css so you may as well namespace your CSS. And ANYWAY your default options may include event handlers or other things you can’t serialize easily into attributes of an element. And you may want to compose tools or find them with CSS so what’s wrong with using CSS classes instead of the element name for that? And ANYWAY you will want to render your tools in a readable way so why not stuff JSON into data attributes which were allowed for exactly such purposes? And ANYWAY you may want to use a powerful templating engine like Handlebars. The only part I am not sure of is the last one.
Seems to me - but I am biased - that we have the optimal approach. If something else comes out we can just turn Q.Tool.define into a wrapper around window.customComponents.define. But our users won’t have to change a thing. They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and Q.requires(module, callback) without worrying what’s underneath. Isn’t it better and more stable?
But everyone got into Angular and React with its JSX etc. I think the main sell was the dirty checking (the model in Angular, the DOM in React). So you can just render a large chunk. I never saw the benefit of that. You should reason about mutations imho. Components are views with their own viewmodel, that’s all. You can update a bunch of state parameters and then call stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff. Is it so hard to call stateChanged() after changing state.a and state.b ? Do you really need to instead grok digest cycles or a virtual dom??
Is there a standard way to define local variables in an Angular template so you don't have to repeat the same redundant expression again and again (or so you can at least give an expression a self documenting variable name so it's not so mysterious)? Or do you have to define an instance variable on your component and figure out how to initialize it to the right value before the template gets executed, with no way to lazily (or repeatedly) evaluate it by putting the calculation inside conditionals (or loops) in the template so they're not run if they're not needed (or to calculate the local variables independently for every loop iteration)? Is there an angular hook or technique that's meant for that, and efficient, and hopefully doesn't involve much arbitrary non-JavaScript gobbledygook syntax, and is at least somewhat standard and well supported? Please don't tell me I shouldn't ever want to do that for some reason of ideological purity or separation of concerns (as if a templating language could ever be called "pure" or "elegant"). The common legitimate use case is ngIf="some expression is not null" then {{some expression}}, and also ngIf="some expressions" ... ngIf="not some expression".
I googled for it, and the solutions of "abuse ngIf's special goofy syntax to name the result of the condition and pray to God it's truthy or don't bother" and "abuse ngFor to loop over an array of one item to give it a name" are not acceptable answers. There were also a few competing and possibly out-of-date "install this non-standard ngLet directive that I hacked up but don't support, but don't call it with an "ng" prefix because that's reserved for the Angular team" -- but isn't there a standard way of doing such a simple essential thing, that the Angular team already thought of and included, such that other people will have some clue what's going on when they see it? And it would be nice to be able to define more than one variable at once per begin/end tag, if you know what I mean. Maybe even without using any begin/end tags, perchance to dream?
Also, is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components, without defining a whole component in all its glory and splendor with multiple files that other multiple files need to import and declare? Or even a global file of shared macros that a bunch of other templates can import, like the globally shared css declarations you can include in local css files? I've seen "ng-template", but I am having a hard time getting my head around it, compared to the simplicity and power of Genshi's py:match, that's based on xpath, and py:def, that precisely follows Python function calling conventions and that you can easily call from any normal expression. And py:match is quite useful for defining concise custom tags (or xpath patterns) that can wrap embedded content. In comparison, ng-templates seems quite clumsy and limited, and confusing about calling and scoping and passing parameters and content, which is nothing like standard JavaScript calling conventions, and reminds me more of the abomination that is Zope METAL templates.
https://zope.readthedocs.io/en/latest/zopebook/AppendixC.htm...
https://en.wikipedia.org/wiki/Template_Attribute_Language#ME...
https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates
I've been using and loving Genshi with Python for more than a decade (and before that, Kid, which Genshi is almost the same as, and before that Zope page templates, TAL, and METAL templates, which inspired Kid and Genshi, but totally sucked), and I love its ability to drop into Python with <?python ... ?> to define some variables or import some functions locally in the template that you can use, with real honest to god multi-line indented Python "if" statements for logic (and Python comments for, err, commenting) instead of Christmas trees of deeply nested ternary ? : operators (or rather postfix conditional "foo if bar else baz" Python expressions). Genshi also has "with" for defining scoped local variables with tags, like <py:with vars="y=7; z=x+10">$x $y $z</py:with>.
And I also love Genshi's py:def for making locally defined or libraries of includable imperative "code snippet" templates you can call just like Python functions (with glorious optional named defaulting args, etc), and py:match for declaring xpath pattern matching templates that can wrap html content as a parameter (so the macro can cherry-pick out and transform different parts of the passed content with xpath), as well as taking attribute parameters.
Another nice feature of Genshi is that for all directives it supports both the attribute form like <div py:if="condition"> ... </div> attached to an element that you want to keep, or the element form that dissolves without leaving an element, like <py:if test="condition"> ... </py:if> . You can also attach multiple directive attributes to the same element, thanks to the way it executes them in a well defined ordered hierarchy that makes practical sense (like "for" above "if", so each iteration of the "for" loop can be conditionalized with its own "if" evaluation), and "def" above all else, so you can define a single tag macro that loops over something then conditionalizes each iteration, then sets attributes on and adds content to the included elements. It's quite concise and expressive!
<div py:def="FizzBusted(count)" py:for="i in range(count)" py:if="i % 3" py:attrs="{'class': 'orange' if i % 7 < 2 else 'blue'}" py:content="['odd', 'even'][i%2]"/>
https://genshi.edgewall.org/wiki/Documentation/xml-templates...
py:def
https://genshi.edgewall.org/wiki/Documentation/xml-templates...
py:match
https://genshi.edgewall.org/wiki/Documentation/xml-templates...
Processing order of multiple attributes (precedence rules you must remember, but they make practical sense, and at least Genshi is quite minimal and only has a few directives): py:def py:match py:when py:otherwise py:for py:if py:choose py:with py:replace py:content py:attrs py:strip
https://genshi.edgewall.org/wiki/Documentation/xml-templates...
These two features (local variables and code snippets) are so important to me, and I'm having such a hard time figuring out how to do them in Angular, that I feel like there's whole a chapter in the Angular templating manual that I missed somehow. Thanks for any tips on how to do this kind of stuff with Angular templates!
I've written more opinions about Genshi and templating on hn before:
https://news.ycombinator.com/item?id=8445252
https://news.ycombinator.com/item?id=10842990
https://news.ycombinator.com/item?id=12365442
https://news.ycombinator.com/item?id=12527839
https://news.ycombinator.com/item?id=16677520
I usually define something in the component, and reference that. If you need to lazily evaluate it you can just reference a function in the component (e.g. "...{{ someFunction() }}...", and have the function do whatever lazy work and/or memoisation you need there.
If you need things to be initialised before the template is ready, you can use one of the life cycle hooks - e.g. ngOnInit(). More details of the different hooks here: https://angular.io/guide/cheatsheet
... that said, it might be easier (depending on context) to "learn to love the bomb" and just rely on Angular's binding to update the template as soon as the value becomes ready after the template has rendered - i.e. don't sweat about getting everything ready before the template loads, just let Angular handle the data binding and let it update the tempalte when the value is ready. This is where the RxJS stuff really shines since you can forget about a lot of the sequencing and just let Angular handle getting the right value on the page when it becomes available. Unless you are doing long network calls or heavy computation, everything is usually in place by the time your brain registers seeing the page anyway so it mostly works out OK and no one notices any thrashing of templates going on under the covers (... although there is a part inside of me that dies when thinking about the performance/wasted CPU cycles).
> is there a way to easily define simple light weight macros ("snippet reuse") so you can repeat the same pattern in one or more components
I have also suffered this recently. I am not sure how this is "meant" to be done, apart from making everything a separate component. I guess the argument is, if you need to use something in multiple places then it is an ideal candidate to become a component. For these "lightweight" components I will usually just use inline templates for the component decorator (rather than referencing a separate HTML template etc), e.g.
@Component({selector: 'snippet-one', template:`<b>My First Snippet</b>`}) export class SnippetOne{}
I agree though that sometimes it would be nice to just have a file you can just easily drop in where you need it.
I get the impression that <ng-template> is actually just directly exposing some low level implementation mechanism, and wasn't specifically designed to be a concise, powerful, general purpose, easy to use templating system, or behave in any way like JavaScript.
I keep trying to work my way through this otherwise pretty good tutorial:
https://blog.angular-university.io/angular-ng-template-ng-co...
>But besides that else template, the use of ngIf also creates a second implicit ng-template! Let's have a look at what is happening under the hood:
<ng-template [ngIf]="lessons" [ngIfElse]="loading">
<div class="lessons-list">
...
</div>
</ng-template>
<ng-template #loading>
<div>Loading...</div>
</ng-template>
>the element onto which the structural directive ngIf was applied has been moved into an ng-template
>The expression of ngIf has been split up and applied to two separate directives, using the [ngIf] and [ngIfElse] template input variable syntax
>And this is just one example, of a particular case with ngIf. But with ngFor and ngSwitch a similar process also occurs.
At this point I'm starting to feel dizzy, like when Scorpius needs his cooling rod changed.
https://www.youtube.com/watch?v=U7SS0YCWVGs
But when I got to the stuff about ng-template with parameter attributes prefixed by "let-", and tacking ";context:ctx" on to the template outlet name, and then having to stick some instance variable into your component source code (which is usually a separate file), my eyes glazed over and my palm hit my forehead. It's like learning a whole new set of cult-like jargon and mythological concepts (Outlets??! Why so many layers of indirection and different names for the same thing?), instead of reusing anything I already know about JavaScript, simply to pass parameters to a template. Maybe this is just a bad example and explanation of ng-template, but I haven't found a better one yet.
@Component({
selector: 'app-root',
template: `
<ng-template #estimateTemplate let-lessonsCounter="estimate">
<div> Approximately {{lessonsCounter}} lessons ...</div>
</ng-template>
<ng-container
*ngTemplateOutlet="estimateTemplate;context:ctx">
</ng-container>
`})
export class AppComponent {
totalEstimate = 10;
ctx = {estimate: this.totalEstimate};
}
How do I make an ngFor loop iterate through a range of numbers, without actually defining a literal array of numbers in the component for it to loop over?
https://stackoverflow.com/questions/36354325/angular-2-ngfor...
With Genshi, you simply do it the standard python way, since Genshi for loops are equivalent to Python for loops: <div py:for="i in range(count)">$i</div>
But I can't figure out how to, for example, use ngFor to iterate from 0 up to n, since it requires an array argument, and there isn't a c-like form like for (init; condition; repeat), or a standard JavaScript way to make a range like python's range(n).
Should I just give up and make a "range" utility method on my "God" service object that I'm passing in anyway? The more gaps like that I have to plug with my God, the more it becomes a God-of-the-gaps object.
I'm currently subscribing to changes in a BehaviorSubject<any[]> instance variable of my selection service "god object":
selection service:
public user$: BehaviorSubject<any[]>;
constructor(
public selectionService: SelectionService
) {
this.userSubscription$ = selectionService.user$.subscribe(user => this.drawUserInCanvas(user));
}
Thanks for the advice!
For your approach, that looks reasonable to me in the 5 lines we have to look at :-) ... so long as you are consistent with the SelectionService and make sure all the changes go through that, you should be fine and your component will get all the updates.
This sort of requirement for consistent management of things like this - i.e. the application state - is a weakness of Angular I think. It is easy to start simple and end up coding yourself into a corner with god services etc. I have used a thing called NgRx in the past for managing state - its the redux pattern and seems to be quite good at making sure state is a bit more sane and well-mananged in the app (at the cost of some boilerplate). One day I hope that there is an official state management mechanism.
Fortunately my app is simple enough that I can just redraw everything whenever something changes, as long as I'm not doing it 37 extra times.
https://en.wikipedia.org/wiki/Zope#Zope_Page_Templates
>Zope Page Templates
>As mentioned previously, Zope Page Templates are themselves XHTML documents, which means they can be viewed and edited using normal HTML editors or XHTML compliant tools (a big advantage compared to other template languages used for Web applications). Templates can also be checked for XHTML compliance so you can be fairly confident that they will automatically expand into proper XHTML.