I'm using a js API and I have to instantiate a class that requires a <div> element in its constructor. However this is only used by the class to do some rendering in the element and I don't need it, I just want to use a method of this class.
I came up with this which seems better than linking to a random <div> element of the page :
service = new API.service(document.createElement("div"));
service.useMethod();
Do you have any better ideas about how to do this ? I don't really know what is good practice in this case.
FYI the class I'm actually using is google.maps.places.PlacesService from Google maps javascript API in order to use the method getDetails on some info I retrieved earlier.
Your approach is OK (I don't know a better approach).
But the issue:
This required node isn't there for fun, the API will print there Copyright-details for the requests(if there are any), and these details must be visible(at least when you display something that is based on the data returned by the service).
So your approach is correct from a programmers view, but it would violate the TOS
Related
With a custom component, you can use the static get observedAttributes() in your web component to specify what attribute changes trigger the attributeChangedCallback() lifecycle method.
However, it seems you can also achieve a similar callback by using the MutationObserver API, documented here, with {attributes: true} to watch all attribute changes, or to refine it more, using a {attributeFilter: Array<string>}.
What's the difference in using the two different methods? Seems like the MutationObserver offer much more flexibility, while the first method is equivalent to having defined an attribute filter.
Yes, minor functional differences.
But MutationObserver takes a lot more boilerplate, and you can't ask the MO which attributes are observed.
It is kinda like saying Why do we need Map, when everything can be done by extending Array
I don't have data, but would say observedAttributes is highly optimized. MO is taking a sledgehammer to drive in a nail.
But as you commented; observedAttributes doesn't give you dynamic attributes.
I'm working on a narrow cast that displays an amount of tickets (an integer with the total added up to eachother) from a 3rd party API. I want to display a notification when this amount increases. I've read about mutationobservers, and that they are good for doing similar tasks like when something gets added or deleted.
The app has a Vue frontend, and a Laravel backend which does the requesting/authenticating. The index blade loads in a Vue component which contains the other components (and distributes the data from the API to child components).
I'm not quite sure wether mutationobservers are good for this specific job, though. Googling really didn't give me great alternatives.
In conclusion, I want to know if mutationobservers are the right tools for this task and what property would work. Better suited alternatives are also welcome.
Using vue, you can use a watcher function to watch for changes in a particular variable (amount). Mutation Observers only watches for dom updates, it won't give you what you want
I'm very new to Angular and MV* in general (short of what I've gleaned from watching other devs work with Ruby on Rails for years), so please pardon what's probably a naive question.
I'm trying to set up a typeahead field where users can enter a street address and get live suggestions from the Google Geocoding API. I started verbatim with this example from UI Bootstrap (the "Asynchronous results" example in the middle field):
http://angular-ui.github.io/bootstrap/#/typeahead
It's working locally, but now I want to extend it to gather other pertinent details of the address and submit those along with the other form data. For example, if the Geocoding API returns a country type in address_components in its results (example here), I'd like to add that to the form data that I POST to the server. (There will be other logic to how/what properties I need to capture, but that's a good starting point.)
Right now, only the formatted_address property returned by the Geocoding API is submitted with the form, as the ui.bootstrap.typeahead directive binds that to the typeahead directive's <input> using ng-model.
So, my question is twofold (but please feel free to address either separately):
If I were starting from scratch (i.e., wasn't bound to the design/implementation decisions made in UI Bootstrap), what would be the most "Angular" way to implement this? Should the directive create an <input> bound with ng-model for every value I might want to capture, and then the controller would handle filling in the ones that are available?
Since I'm not starting from scratch, what is a reasonable way to augment the existing code to provide this functionality? Is there a way that I can add features to the existing directive? Does this behavior belong in the controller, or would I be better off abstracting it into a service? Or am I overthinking this - is there a simpler or better way that I haven't considered? Per the UI Bootstrap example, the only obvious place that I see to put this code right now is in the success function passed to .then() within $scope.getLocation(), where I'm handling the $http response, but my gut says that that's not ideal. All I can imagine doing there is adding properties to the form values object that I'm building (i.e., the object I'll POST on form submit), but then I have to know the names of those properties, so now my controller is tied too closely to the form in which it's used.
Thanks in advance for any help. I hope this makes sense. Since I'm still grasping the fundamental concepts, it would be especially useful if you could point me to any existing code that does something similar, or refer to specific documentation or articles that could lend some insight.
On #1, the Angular-UI design is a very "Angular" way to implement it - I don't see any issue with it. The directive takes a list and returns the selected list item. This is how the controller sees it. Put it in other words, another directive, say a typical <select> or a custom infinite scroll or a yelp-style map, would provide a different View behavior, but would be functionally equivalent from the controller's point of view - which keeps the separation of concerns intact, and thus very MVVM-y.
I also think that you have some confusion about ng-model. ng-model should be used with input controls (not only <input>) with which the user interacts with directly. In this case, the only input is a typeahead directive.
On #2, it depends whether the the "other pertinent details" are natural part of the service API or if they need to be fetched after selection. Assuming the former, the correct place is, in theory, in a service. The controller should only marshal data from Services to the ViewModel and back.
For your specific example with the country code, the API returns multiple components in address_components property. The extraction of the country code - as well as checking if it exists or not and other business logic - is best to handle in a service, probably with another service API after selection, or when the original list of addresses is obtained - whatever makes sense for your case.
For a simple case in a simple app, like in the example, you could just modify the $scope.getLocation() function to return a list of actual objects that your controller (or rather your ViewModel) actually needs, and then have the View return the selected object (as per #1).
I am a newbie to html/css/javascript and code like this really scares me:
http://code.google.com/apis/maps/documentation/javascript/overlays.html#InfoWindows
Is assigning html to javascript variable a good practice? or I hope there is a substitute.
There is nothing wrong with it. After all, it is really no different then typing the same thing outside of the javascript block.
I do however find, that the formatting and the likes can be annoying. On use JQuery a fair bit, and depending on what I might be doing I might use a .html() or .clone() method to create html form another element.
JQuery also has a template plugin which when used does allow for you to get slightly better formatting, and you can also specify dynamic values. Which is great for creating dynamic tables that update with Ajax for example.
Another side note, the fact that example you gave was on a Google site, would usually be enough to convince me it is OK to do ;)
There's nothing bad in it. People have been doing this since there was a thing called DHTML :-)
AFAIK, this is one of the most performant ways to build a part of document (later to be inserted to DOM or whatever).
In this case you have to, since google Maps API requires explicitly to pass a HTML content (and not a reference to some hidden element in page or loaded via ajax).
This don't mean it's a bad practice: for example, I always use a HTML string along with some custom template system, so that I can pass infowindow HTML in a loop, changing dynamically some chunks of markup with data retrieved by a JSON.
Anyway you can still use an element into the DOM and then pass its outerHTML string to the API if this makes your application more performant with an improved maintainability
I'm building a web app with a lot of ajax calls to be made.
Should I be trying to keep a small number of methods, and just pass in information about what type of request it is, and then switch based on that type inside the method
or
Many smaller methods, so don't have to pass in type, but more code to write setting up each method.
Currently I'm passing type from the id of the element being interacted with in the html, and then this tells me what I'm trying to do
row-action-data-id (I then split this in the functions, to work out what needs doing)
Are there any best practices for patterns like this?
its a judgement call. you always want to refactor out any duplicate code as much as possible but its important that your code is readable and maintainable.