5 ms·

It absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanil

It absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanilla" Javascript when using Angular. I recently integrated some externally written d3 javascript code and it works as expected without forcing a conversion to "the Angular way". Finally, I certainly dispute that Angular is too slow. Our Investmynd app has a fairly data and interaction heavy front end, and its performance is quite snappy if I do say so myself. :) Now what I do think is true is that Angular is a fairly complicated beast, which when combined with the poor standard documentation, makes it a non-trivial endeavor to learn and use properly.

jamra 11y ago
I'm happy that it works for you. I'm just sharing my opinion of the framework so please continue to use whatever makes you happy. As far as using services to communicate, I personally believe that its simpler to emit events. My absolute favorite way is how Mithril makes properties accessible anywhere. That way, you can just pass references around. It's not so important how you communicate, but the complexity of doing so. I believe that in your last sentence, you might have described the point better than I. It's a complicated beast. For that reason, you have to work within its domain. You can't invent your own way of doing things. You can't apply your trade in the way you want to. I suggest you play around with a React app and pay attention to the best practices of organizing your own javascript code more than what React itself does. It's refreshing.
- thoman23 11y ago
  I do plan to continue to use what works for me. I also plan to experiment with React. I'm just pushing back a bit on the suggestion that Angular is not a viable framework in its own right. Regarding services vs. events, I guess that's down to personal preference. I find a singleton service holding shared state much easier to reason about and maintain than I do events (for certain things, like shared client side session state...I certainly do use events when appropriate). Regarding "doing things your own way", I guess that's a personal preference as well. Personally I like to nail down a few common implementation patterns that get the job done and then repeatedly use those and save my focus for the business problem at hand. I'm fine with the framework strongly suggesting or even requiring those implementation patterns as long as they work and aren't overly cumbersome.
wwweston 11y ago
> It absolutely is not difficult to share state across Angular controllers. Services work great for this. From what I saw in the last Angular app I worked on, the ideas that services can work for this and that things can get difficult fast when sharing state across controllers aren't at odds.
- thoman23 11y ago
  Hmm, shared state in and of itself can certainly cause difficulties (hence the recent focus on immutability and FRP), so I agree with what you are saying. However, if you are going to have shared state, I find the Angular service singleton approach as good a way to handle it as any.

jamra 11y ago

I'm happy that it works for you. I'm just sharing my opinion of the framework so please continue to use whatever makes you happy. As far as using services to communicate, I personally believe that its simpler to emit events. My absolute favorite way is how Mithril makes properties accessible anywhere. That way, you can just pass references around. It's not so important how you communicate, but the complexity of doing so. I believe that in your last sentence, you might have described the point better than I. It's a complicated beast. For that reason, you have to work within its domain. You can't invent your own way of doing things. You can't apply your trade in the way you want to. I suggest you play around with a React app and pay attention to the best practices of organizing your own javascript code more than what React itself does. It's refreshing.

thoman23 11y ago
I do plan to continue to use what works for me. I also plan to experiment with React. I'm just pushing back a bit on the suggestion that Angular is not a viable framework in its own right. Regarding services vs. events, I guess that's down to personal preference. I find a singleton service holding shared state much easier to reason about and maintain than I do events (for certain things, like shared client side session state...I certainly do use events when appropriate). Regarding "doing things your own way", I guess that's a personal preference as well. Personally I like to nail down a few common implementation patterns that get the job done and then repeatedly use those and save my focus for the business problem at hand. I'm fine with the framework strongly suggesting or even requiring those implementation patterns as long as they work and aren't overly cumbersome.

wwweston 11y ago

> It absolutely is not difficult to share state across Angular controllers. Services work great for this. From what I saw in the last Angular app I worked on, the ideas that services can work for this and that things can get difficult fast when sharing state across controllers aren't at odds.

thoman23 11y ago
Hmm, shared state in and of itself can certainly cause difficulties (hence the recent focus on immutability and FRP), so I agree with what you are saying. However, if you are going to have shared state, I find the Angular service singleton approach as good a way to handle it as any.