Angular ui-router, save state by url/url variables? - javascript

Have an interesting problem I'm trying to see if I can solve with angulars ui router plugin. What I am trying to do is save a view state by means of a customized url.
I have set up a very basic example to see if this is possible then I would like to abstract upon this if it works!
So I very simply have a
$scope.test = false;
and then on the page there is an ng-click that toggles this test variable between true and false. So what I am trying to see if I can save that state and pass it in - so say if i change it to true, I would like to be able to save a URL and then go to that, when i come to that, this variable would then be changed to true (instead of it's default false in the controller)
So I was thinking I could try something like
url: "test/{form_id}"
(I'm assuming this is how this works), however I might want to pass more than just an id. BEST case scenario is I could pass an object entirely via url (or rather reference to one, I know passing an object sounds silly), but otherwise I'm assuming on either end I would have to set up a way to make the string for the id and a way to interpret it. If i could fashion it to be polymorphic that would be fantastic, however my first steps are trying to be able to do it on a low level.
So my thinking is - every time you click to change it sets a variable which can then be set on the url. If the url is given to someone who is logged into this app and goes to that view, the controller would know from the url that it needed to change the $scope.test = true on load. I'm wondering if it's possible to conquer this with angular-ui-router, and if so if someone would be willing to provide some guidance I would be most appreciative. Thank you for reading!

You can't really pass a reference since you are talking about 2 different instances of the app. But you could JSON encode your object, urlencode that and pass it on the URL. If that is too big it will not work in all browsers though. It would also be "better" in many cases to have a more semantic URL i.e. instead of passing a big old blob, use meaningful parameters and pass those.
The documentation for $routeParams is at https://docs.angularjs.org/api/ngRoute/service/$routeParams

Related

Routing page state changes in angular

Say I have an angular app which is simply a single page that displays an array of strings.
Now say I want to create a filter for my displayed strings, then append that filter to the page URL so the filtered results can be linked to. As example url might be, "/filter/myfilteredword"
In this example I would still want to use the same controller and I wouldn't want to use a template URL as there is only one page. I also need to be able to pass in the filtered string as a param.
I've tried to set this up using angulars $routeProvider and $routeParams, however I'm not having much luck and I'm not 100% sure this is the correct way to go about it.
Any advise would be really appreciated.

Using Angular, where should I store my constants?

This question has less to do with how to do something, but more about best practices and what do others do?
I have a few services where I am using some kind of an external API (in this case the session storage api in the browser), where I am reusing the same constant string, the name of the company and the application, let's call it "ACME.Storage.", and this I want to prepend at the start of every "key" string. I see my options as:
I can just reuse the string "ACME.Storage." in every call.
I can create a JavaScript function where I create a new storage object that is configured with "ACME.Storage." once. That way, "ACME.Storage." appears once in my code.
I can create a local variable ans store "ACME.Storage." in it, then reuse that. Again, the string literal appears only once in my code.
I can create a separate javascript object that I can share.
I can use an AngularJS "constant"
I can add as a field to the app of config file.
I can store it somewhere where localized literal strings (even though this particular string isn't localized) and get it through a translation service.
I'm leaning toward using the "constant" service 'cause it's the one that's easily injectable. My only concern is that it's less encapsulated than some of the other options.
Opinions on the best practice?
To expand upon what Whishler posted, you can (and probably should) use the Constant module that Angular provides. Complete docs are found here: http://docs.angularjs.org/api/ng/type/angular.Module. Services are a common place for constants, but the Constant modules get applied before other provide methods. Another option would be Value, but it does pretty much the same thing.
Generally, I put constants into a service.
Depending what I'm doing, I may create a service that does nothing but store related constants. Or I may add them to another service representing a 'model'.
I'll also add that JavaScript doesn't officially have constants; so unless you wrote some code--such as your own accessors--you're just dealing with a variable that could be changed during the execution.

Is there a way to tell angular $location not to discard array query parameters that come before the last one of the same name?

When redirecting in AngularJS to a route such as
myapp.com/search/?someParam=someVal&someArrayParam[]=someArrayVal&someArrayParam[]=someArrayVal2
Angular will automatically discard someArrayParam[]=someArrayVal and leave only someArrayParam[]=someArrayVal2 in the URL.
Is there a way to prevent this? I would much like to be able to send GET array values through routes for deeplinking complex interfaces. Right now the workaround I've come up with is to use $loc.url("/search/?filter="+JSON.stringify(scope.searchData)); but I'd much prefer the former.

Can I make Rails' CookieStore use JSON under the hood?

I feel like it should be obvious doing this from reading the documentation, but maybe somebody can save me some time. We are using Ruby's CookieStore, and we want to share the cookie with another server that is part of our website which is using WCF. We're already b64-decoding the cookie and we are able to validate the signature (by means of sharing the secret token), all of that is great... but of course the session object is marshalled as a Ruby object, and it's not clear what is the best way to proceed. We could probably have the WCF application make a call to Ruby and have it unmarshal the object and write it out as JSON, but that seems like it will add an unnecessary layer of complexity to the WCF server.
What I'd really like to do is maybe subclass CookieStore, so that instead of just b64 encoding the session object, it writes the object to JSON and then b64's it. (And does the reverse on the way back in, of course) That way, the session token is completely portable, I don't have to worry about Ruby version mismatches, etc. But I'm having trouble figuring out where to do that. I thought it would be obvious if I pulled up the source for cookie_store.rb, but it's not (at least not to me). Anybody want to point me in the right direction?
(Anticipating a related objection: Why the hell do we have two separate servers that need to be so intimately coordinated that they share the session cookie? The short answer: Deadlines.)
Update: So from reading the code, I found that when the MessageVerifier class gets initialized, it looks to see if there is an option for :serializer, and if not it uses Marshal by default. There is already a class called JSON that fulfills the same contract, so if I could just pass that in, I'd be golden.
Unfortunately, the initialize function for CookieStore very specifically only grabs the :digest option to pass along as the options to MessageVerifier. I don't see an easy way around this... If I could get it to just pass along that :serializer option to the verifier_for call, then achieving what I want would literally be as simple as adding :serializer => JSON to my session_store.rb.
Update 2: A co-worker found this, which appears to be exactly what I want. I haven't gotten it to work yet, though... getting a (bah-dump) stack overflow. Will update once again if I find anything worthy of note, but I think that link solves my problem.

Should ajax calls go through as few as possible entry points to an application or many specific methods

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.

Categories

Resources