Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
this is probably a stupid question but here it goes anyway. I know that services are like singleton that's good for storing shared data. However I've been struggling with some concepts - Is it true that when using built-in directives like ng-repeat, do we always have to write "middle-man" methods to access/manipulate the shared objects in services? E.g
we have
appModule.service('fruits', function(){
this.items = ["apples", "bananas"];
});
To use ng-repeat to access these items, we must first need to write controller method like
appModule.controller("fruitsController", function($scope, fruits){
$scope.getFruits = function(){ return fruits.items;}
});
How about using custom directives then? Given that the service can also be injected into a directive, it will have direct access to the service. Is there any pros and cons of either methods?
So I think you're asking "Why not use custom directives for everything instead of controllers?"...
Well, basically because that would be harder to test. It's sort of like asking "Why separate code at all?".
The purpose of a directive is to provide two way access between your model and your view (the DOM) and handle setting up those interactions.
The purpose of a controller is to encapsulate "business logic" for the app.
Can you mix them both into a directive? Yes. Should you? Probably not.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am trying to create a long-form page that will have 5 fields per each page with continue button. What is best format for coding alignment especially in react js with functional components only.
I have 3 approaches in mind.
Keeping each page fields in different pages like page1, page2, page3 and then access in parent.
Keeping all fields in one file and accessing those using switch case by passing page numbers.
Keeping all fields in one page and loading all fields, but hiding some fields based on the page number.
If there is any other best standard approach that will reduce future maintenance, and fewer coding changes, with less duplicate code so... on please prescribe hear.
The best approach according to me would be making a single component that will hold all the form values and conditionally render them on screen. What you can do is, create three div's that will render conditionally like:
{ step === 1 && <div>{"Your form here"}</div>}
The best part of this approach is that you will have all the form data at single place. And then you can easily pass that data to an API and make a request.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
As an angularjs developer i want to know when i should use attribute versus an element
AS per my understanding and development knowledge Use an element when you are creating a component that is in control of the template. Use an attribute when you are decorating an existing element with new functionality.
But i am not sure ... please suggest
Angular directive documentation
Original answer by ckruszynsky:
The angular guidance says that you should use the "element"
restriction whenever the directive has full control over it's template
meaning it has a template that it is rendering out, etc.
For attributes, they suggest to use these only when you are adding
"behavior" to an existing element or decorating an existing element.
For example, think of the ng-click directive, this is used a attribute
not as a element because the click directive is just adding the click
behavior to some element.
Another example would be the ng-repeat directive, it is also used as
an attribute not as a element because it is going to repeat the
element in which it is being used in.
Now, this guidance is from the angular documentation; however, I don't
know necessarily that element vs. attribute is going to give you a
"better" approach it's more of a convention.
Now if you have to support older browsers, then you may want to
consider using either the comment or class directives.
My personal preference is to just use the attribute restriction;
mainly because people that are new to angular get overwhelmed at first
when they see the restrict and it's variations of the options that can
be used.
This question is quite opinion based, personnaly i use only attributes but i'm probably not the one to follow
However i can address some points following how HTML is designed :
element fits for a component (like an input, table).
attributes fits for options that influence the behaviour of your component (like type="text"). But they can be used as components too, as long you don't use two of them in the same element.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
why in AngularJs name conventions, the name of a controller should begin with uppercase letter while others seem to begin with lowercase letter?
It's recommended to name classes with uppercase first letter to distinguish them from simple functions. Since Angular controllers are technically constructor functions which construct new controller instance objects - for consistency it is better to reflect this fact in the name too.
On the other hand, injectable services are not constructors, they are already objects (created behind the scene), so there is no need to name them with uppercase - they are not constructors you are (or Angular) going to use to create new object instances with new keyword.
But of course, this is just a convention, not very strict. Just a nice consistency.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I just don't see the point of encapsulation, I see that in some cases you can modify a getter/setter to modify the behavior of something or keep track of state, but whenever I am creating a non-conventional getter/setter, I use a word like "modify," or "obtain," so what is the point of wasting hours writing repetitive methods that are practically pointless and inefficient?
I just don't get it, when I was a wee young programmer, I was told by some guy in an IRC, that not having it was the cause for a bug in my program, but I have known for years now that is not the case, I've just been doing it anyway, so what is then point?
If I need to refactor later there are ways around it weird ones but they are ways at least in languages with overloaded operators, and API's don't always have to be backwards compatible so I don't see the point.
Can anyone enlighten me to the necessity of encapsulation?
In many cases you are right - small programs doesn't need encapsulation probably.
Some MS infrastructures (C#/WPF I think in several binding scenarios) requires encapsulation (using properties) and will not work without it.
If you do more in get / set than changing the value or returning it - it will make your code nicer and more robust (do checks, or other staff in the setter for example).
No one forces you to use it anyway...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions must demonstrate a minimal understanding of the problem being solved. Tell us what you've tried to do, why it didn't work, and how it should work. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I'd like the buttons in my app to give feedback, as for example demonstrated here.
I'm wondering how I should structure my code. I want to be able to change the classes, the text and maybe disable them upon click. I guess a directive is the right fit, but the exact changes that will happen depend upon the button, and putting content or class names inside a controller or directive doesn't seem very right.
Right now i have a very generic directive that takes all options through additional attributes, but I wonder if someone can see a better way of doing it?
Always start with a very simple directive and extend with CSS classes. If you want to do a particular work well anything you can use a function of the controller. I think you made the right choice. Think to look angular UI for best practice : http://angular-ui.github.io
You can add event on each action:
// Create a new instance of ladda for the specified button
var l = Ladda.create( document.querySelector( '.my-button' ) );
// Start loading
l.start();
// Will display a progress bar for 50% of the button width
l.setProgress( 0.5 );
// Stop loading
l.stop();
// Toggle between loading/not loading states
l.toggle();
// Check the current state
l.isLoading();