Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes AngularJS Developers Make

airpair.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Mistakes AngularJS Developers Make

#51

Post by jzig »

dougcorrea wrote: post #16
maaaats wrote: post #7

Earlier quoted context omitted.

I understand the grouping of the JS files by feature. But I have a hard time including the partials/HTMLs with that. Because when building (concat, minify etc) the project, they will then need to be copied around and all template-references updated. It's easier instead to just dump all of them into one place and copy that folder, no need to update references etc. then. Any ideas on how to solve this?

I use this Yeoman generator that uses a very good structure like recommended above https://github.com/cgross/generator-cg-angular

We're using the same generator for a large government app. "Widget" partials are stashed in their respective folders under /widget while /services, /directives, and so on are contained in the root folder. HTML/CSS/JS stored in each folder. It's all super organized and modular IMO. Of course it helps to be working with the creator of said generator.

Re: Mistakes AngularJS Developers Make

#52

Post by weavie »

joesmo wrote: post #34

I disagree with #10 (Using jQuery). Why would I rewrite perfectly good widgets (jQuery plugins) in Angular (or any other library) when I can create a thin Angular wrapper around them? Because the philosophy is different? That's hogwash. At the end of the day, you're still manipulating HTML no matter what library you use or don't. This is pure nonsense, not to mention impractical, and bad advice.

The rule I've found works best is to avoid jQuery until absolutely necessary, and definitely not until you have fully learned Angular. At first I would find myself reaching for jQuery for all kinds of things that ended up just being a couple of lines in Angular. It has actually been a while now since I've actually touched it, and thinking about it, I don't think I've even included it in my latest project. No doubt I will end up needed to pull in some third party control at some point which will necessitate I include it, but really I haven't missed it.

Re: Mistakes AngularJS Developers Make

#55

Post by seivan »

vectorpush wrote: post #47
benlesh wrote: post #37

It's a good article, but a good portion of these aren't "mistakes" but rather "opinions". #1 isn't a "mistake" it's a preference, really. Also, I'm really not sure about putting the template files in the directory with the other files. Then I guess I'd have to add something to my build script to copy them to a hosted directory? #3.1 IMO, Is actually more of a mistake. Imagine you have 3-4 modules, which one do you de…

> #11 - Overly "DRY" Jasmine tests. Agreed. I've gone down that rabbit-hole myself more times than I'd like to admit. It's very easy to waste time DRYing up your test suite with beforeEach calls; there is a kind of nagging temptation to reduce every spec down to the minimum number of lines required, and it's a pretty cathartic way to avoid doing real work (especially if you're taking a TDD approach), but ultimately,…

Been there as well. I call it being clever with your test suites. Figuring out a way to hack your test suites so you can write as little code as you can. Except your test suite ends up unreadable because of all the magic you made for... DRY.

Re: Mistakes AngularJS Developers Make

#56

Post by boydjd »

nawitus wrote: post #44
lars wrote: post #32

This is possibly better called a list of framework design mistakes made by the AngularJS team. #3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be i…

>#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production. I think the real mistake in that scenario is not minifying the code until "in pr…

> I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one.

How are you debugging minified code?

Re: Mistakes AngularJS Developers Make

#57

Post by grumblestumble »

joesmo wrote: post #34

I disagree with #10 (Using jQuery). Why would I rewrite perfectly good widgets (jQuery plugins) in Angular (or any other library) when I can create a thin Angular wrapper around them? Because the philosophy is different? That's hogwash. At the end of the day, you're still manipulating HTML no matter what library you use or don't. This is pure nonsense, not to mention impractical, and bad advice.

Yep, I agree with this one completely. I'd go even further and say the opposite is true. I see a lot of angular projects needlessly using $scope for handling pure UI rendering issues which do not need to be hooked into the $digest cycle, which can really have an impact on performance as it adds unnecessary watchers. Need to adjust the layout of a UI element? Creating a scope property and binding to ng-style is not the way to go.

Re: Mistakes AngularJS Developers Make

#58

Post by grumblestumble »

boydjd wrote: post #56
nawitus wrote: post #44

Earlier quoted context omitted.

>#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production. I think the real mistake in that scenario is not minifying the code until "in pr…

> I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one. How are you debugging minified code?

sourcemaps?

Re: Mistakes AngularJS Developers Make

#59

Post by grumblestumble »

josekpaul wrote: post #39
lars wrote: post #32

This is possibly better called a list of framework design mistakes made by the AngularJS team. #3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be i…

I concur: this is a good list of issues. One additional thing I found was composition/inheritance of controllers with $injector.invoke.. breaks in minified code because of issues similar to #3.

I'm fairly certain that the majority of Angular developers would tell you that controller inheritance is an anti-pattern. This is what services are for. The furthest I go is using services as controller mixins, eg. $scope.commonTools = CommonToolsMixinService.call($scope);

Re: Mistakes AngularJS Developers Make

#60

Post by nawitus »

boydjd wrote: post #56
nawitus wrote: post #44

Earlier quoted context omitted.

>#3: The fact that the default dependency injection mechanism breaks when minified means it should never have been included. If this mechanism sneaks in anywhere in your app (and there are plenty of third party libs that use it), it wont start breaking until you bundle and minify the code, at which point you may already be in production. I think the real mistake in that scenario is not minifying the code until "in pr…

> I think the real mistake in that scenario is not minifying the code until "in production". You should minify your code from the day one. How are you debugging minified code?

That's a big problem. Firefox and Chrome these days support debugging source mapped files. However, I'm running through two source map steps: TypeScript to JavaScript and JavaScript to minified JavaScript. For whatever reason the browser debuggers don't work that well with this setup. They're buggy and make the browser very slow. I often do have to resort to "console.log" debugging. On the plus side I'm always running code like it's run in "production", which will make it easier to catch any bugs resulting from minifying.
Post reply on HN