That's probably how I'd do it. You could always define your own session cookie using $cookie directly, or use a localStorage solution as well if things get big. There may well be some kind of shim somewhere to do fallbacks and stuff.
On Thu, Jul 31, 2014 at 3:07 PM, Tom Spruce <[email protected]> wrote: > Hi Internet People, > > Today at work, I was given a spec to remember specific <select>'d options > on a form after a user refreshes the page. No not on form saves, but when a > user makes their selection so that it is saved temporarily on their session > before they commit to it on the server. This meant data binding to the > $cookie. I would like your feedback on my solution to this request. Here's > the snippet: http://plnkr.co/edit/YoHGRPeZlAC9NqVJuxvI?p=preview > > It is a service where you pass the scope, the form object in that scope > that needs session saving, and a strings of the property of the form you > want to save. > > Is this an optimal solution? More specifically, does it break any best > practice? > > My worry is if this service will create too many watches or pollute the > session cookie. > > Best, > iā¤computers > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
