|
Knyteguy posted:What would be better to (re) invest my time into learning? Angular or Ember? I was checking out Ember fairly heavily at one point but I haven't kept up in the past few months. Both provide the same tools you'd need for building complex front-end applications (data-binding, routing, templates, components). Both do a form of MVC. The major difference is Ember is highly opinionated and takes a bit longer to get started with (conventions, API), with the payoff being following the Ember way you'll have a well-structured application that's going to be more maintainable, etc.. If I were starting today, I'd pick Angular. The adoption rate is higher, it's easier to get started with and you have more flexibility in structuring your application (flipside, you may structure it wrong). Also some concepts translate well if you have experience working in the back-end, like dependency injection and services. There's been a push lately to get more Angular best practices out since every project you see posted does it wrong so read those if you pick Angular.
|
#
¿
Dec 7, 2013 16:50
|
|
|
|
| # ¿ May 2, 2024 01:26 |
|
|
an skeleton posted:It's realllly complex. We have a service that takes in strings as parameters and turns them into parameters for the nggrid via its API. Yes we were trying to manipulate the ng-grid by wrapping it in a form tag in html and then manipulating it with a $watch that iterates thru the grid whenever there is a change and if one of the ng-grid's form inputs was $invalid, then it turned off the save button. Problem is the $valid variable seemed to be unattainable from within the controller. Anyways we came up with the solution of just searching the document for elements with the "ng-invalid" class which is applied on invalid input, and if there were any then the save button was ng-disabled. This had a couple of other complications but basically worked Give your form a name. The form directives exposes a form object on the parent scope and calls it whatever the name attribute is. This object has all the state methods: $valid, $pristine, $dirty, etc., as well as all the ngModel inputs that are in that form and their validation states. Please don't do the thing you outlined.
|
|
#
¿
Feb 5, 2014 01:58
|
|
|
Thermopyle posted:Maybe just testing that it acts on the DOM like you expect it to...like making sure that when a List component is mounted it creates some li's or whatnot. If you consider a React component as a function that takes params (via props) and returns HTML as output, there's nothing wrong with your method of unit testing.
|
|
#
¿
Jun 24, 2015 01:04
|
|