My understanding of angular services is that they are used to access external data sources amongst other things.
So let's assume I have a service to access feeds, that deals with the ATOM parsing, etc.
Now, let's assume a controller needs to access several feeds.
Is there a way for me to parameterize services as they are instantiated? Since services are singletons, do I need a service factory factory? Should I be using the same service and passing details of the particular feed each time? What if I need to make more than one calls to the same feed and would like a dedicated object to speak with? (think websockets instead of feeds).
Is there another approach altogether that would work for this?
Is there a way for me to parameterize services as they are instantiated?
Not really. You can inject things into a service – e.g., another service – but I don't think that will help you here.
Since services are singletons, do I need a service factory factory?
I don't know how you would write that, but again, I don't think it would help here.
Should I be using the same service and passing details of the particular feed each time?
Well, as I asked in the comments, if you are dealing with a fixed set of feeds, I would hard-code them into the service (or maybe have the service fetch them from a configuration file on the server), and allow the controller to ask for them by name or some ID.
If you need something more dynamic, then I think you'd have to pass in the feed details to the service.
In either case, I think one "atomFeed" service would be sufficient.
What if I need to make more than one call to the same feed and would like a dedicated object to speak with?
I would probably still use one service. I'm not sure what the issue is here though.
Related
I have more of a style question. So I have my services classes with my http calls. What would be best practice in Angular
http.get("/api/some-stuff")
or
http.get("${api.url}"/some-stuff
What would be the better approach? I noticed with the first one, I need some sort of proxy and url rewrite on my web server after I build the project.
For the second approach I need some sort of env deployment. But as said. What is best practice here?
Yes, this is just opinion question and i would like to say, that from my point of view the best practice would be to have in memory service wich will handle your rest api uri and:
http.get(urlResolver.getBase() + urlResolver.getYourEntryPoint())
I was studying angularJs last week and there's something I'm not sure about.
For example, in a project that has some CRUDs of Student, Teacher and Supplier. Is it a good practice split the services/factory for each models (student, teacher and supplier)? or Is it better use one generic service/factory for the same models, like "write once, and run in everywhere"?. I think the second option maybe works for big projects, because you can write less code, but I have no idea about the maintenance.
Obs: The service/factory reffered above has functions with $http to list, add, edit and delete a registry from database.
And Is there any detailed style guide with best pratices for AngularJs?
Thanks in advance!
If you can manage the API endpoints at the back-end side you can create your services based on $resource. All you need (at the front-end side) is to set the endpoint URL. By call of $resource predefined methods like get, save, delete and etc. (you can add your custom methods as well) the $resource will submit HTTP requests with particular HTTP methods (GET, PUT, POST, DELETE) to the defined API endpoint.
If you want to stick to angularJS I would advise you to check this angularjs style guide from Todd Motto, it's most likely best one online:
https://github.com/toddmotto/angularjs-styleguide
Really has best practices using component based architecture. You will improve your code drastically and even merging to Angular would be easier.
I am working with AngularJS 1.x on a web application which should be extended to provide a sort of API to customize some of its behavior by third-party developers. Obviously these developers cannot modify directly the source code of the application but must use the API I provide to extend it.
I provide you an example of the type of extension I want to provide with the API.
I have a page which displays a form. This form is dynamic and it is described by a JSON. There is an engine in the AngularJS page which read the JSON and render the form. There is also an AngularJS service, let's call it formService, which has the following methods:
getForm: using a REST API, get from the back-end the JSON describing the form structure to be rendered front-end side.
loadData: using a REST API, loads from the back-end the user data to be displayed.
saveData: using a REST API, saves into the back-end the data provided by the user in the form.
I need to provide an API that permits to third-party developers to customize this service. The third-party developer could:
load a different JSON to be displayed in the front-end. He/she can, for example, use a different REST call from the one I provide or build the JSON locally, inside the service.
load a different set of data to be displayed in the form. For example, his/her form could have different fields from the one I provide and so it could need other data.
save different set of data. Same as above.
My question is: how can I provide this kind of extensibility to the app?
The only option I found was to use the AngularJS decorator to let the third-party developer to decorate the formService and provide his/her own version of the methods. In this way the developer can extend or change implementation of specific methods or substitute the whole service implementation.
I made a lot of research and I think this is the best "angular style" solution to extend an existing service from a third party.
Do you know any other good solution to enable third-party developers to customize the behavior of an existing service?
Actually your question is too broad and I dont think your idea is so good in general, but nvm. You can use $injector:
.directive('strangeForm', ...
link : function() {
formCfg = $injector.get(attrs.formService).get();
data = $injector.get(attrs.dataService).get();
onSave = $injector.get(attrs.saveService).onSave;
}
<form strange-form form-service="service1" data-service="service2" save-service="service3"
We are working on a RoR project implementing an LMS. We need to send data to an external REST service provided by an external server. The data is sent when certain events are accomplished, it is possible that some of those are not triggered by the client (clicks, etc.).
Also, we need to keep consistency in our rails models, because we need to keep record of the user activities.
There is a library provided to work with the API, written in JavaScript. It makes most of the work easy, so we would like to use instead of creating our own implementation for the API requests.
What are the differences between each of the following approaches? Would one be preferable to another?
Use javascripts to send the data, inserting the snippets in the
views, from the client, but having the client execute this might have
some serious implications (scores changed, false success, etc).
Use a NodeJS server to execute the Javascript but we don't really know how to communicate with our main server (Rails)
And finally, use a HTTP client from the Rails app to send the requests to the service. However we don't know exactly how to do it, also there is the question of where this code goes in the MVC pattern.
Option #1, as you've likely realized, is out of the question. For the client to make API calls on your behalf, you would need to send them your secret key/token/whatever you need to authenticate with the API. But once they have that, they could just use a script console to make whatever API calls they want "as you". This would be pretty disastrous.
Option #2 might be prohibitively complex -- I'm personally not sure how you'd go about it. It is possible, using a library like therubyracer, to execute JavaScript code from Ruby code, but there is some degree of sandboxing and this may break code that requires network access.
That leaves you with Option #3, writing your own Ruby library to interact with the API. This could be easy or difficult, depending on how hairy the API is, but you already have a JavaScript version on hand (and hopefully docs for the REST service itself), so combined with something like RestClient or HTTParty the path forward should be clear.
As for where the API calls would fit in your Rails code: If you have models that are basically mirroring the resources you're interacting with through the REST service, it might make sense to add the relevant API calls as methods or callbacks on those models. Otherwise it might be fine to put them in the relevant controller actions, but keep an eye on your code complexity and extract to a separate class or module if things are getting ugly.
(In cases where you don't need to wait for the response from the API before sending something back to the user, you may want to use DelayedJob or similar to queue your API calls in the background.)
I am new to AngularJS, the notion of scopes really confuses me. I have a situation where I want to modify a an object or a variable from different scopes. Here is why:
in my application I want to centralize the user notification Controller and notification view.
In the middle top of the page. I separate my code as follow: each view has its controller I think its fair reasonable. I want to inject a service or some common object that when invoking its function with some string parameter on a common place but, I figured out that I can not inject $scope service. So, when
What you want is to communicate between controllers. That is fairly easy to realize whit a service that can broadcast messages (or objects) between controllers.
There is a nice youtube about this:
http://www.youtube.com/watch?v=1OALSkJGsRw
OK here what I have done in my application. I am a java programmer and I used to work with GWT
In GWT ther is a very nice design pattern, to notify widgets across the application, called EventBus. In angular I tried to do something similar. Here is the code link in gist