Nice talk, I think the issue I'm chewing on lately aligns with the speaker's ideas about the role of the router vs state transitions. In particular, any user who navigates directly to a given application route by directly typing in the URL bar should see the same thing. That's part of the data model- the data that comes off of the backend that defines stuff like document.title and so on.
However, the view itself tracks a lot of state that isn't related to the content of the model itself, but rather how it is presented- This element is collapsed, that is expanded, and the document.title form is filled out to change the title. Visiting the page directly, or refreshing the page with the reload button, should reset these view state objects to their default state. That said, there are situations where you may well want to preserve view state across state transitions. If I hit back on the browser, it would be cool if I could end up with the same expand/collapse and tab-selected state when I get back to the page. This is kind of like both previous states and sticky states in the link that Stephen provided. My naive idea was to use an injectable service to do something like push my current $scope into a stack and hand my $scope to the service after default initialization, so that the service can override view variables that it thinks ought to be different from default when it can do that. That turns out to be a terrible idea, if for no other reason than that I handle a lot of my ng-repeat templates with isolate-scope custom directives (<reaction-stack item="profile"> to have an expandable thing attached to this particular profile, but with an outer ng-repeat="profile in profiles"). That way I don't have to do weird things with view state array variables when I am ng-repeating over a list, but it makes restoring state a lot harder, since these isolate scopes will get lifecycled out. There is probably no good way to handle this in a productive, general case, without radically altering the $scope lifecycle model and how controllers get instantiated. Will have to see if there's utility in the stack model for the limited issue I'm dealing with now, or if I should just stick with the modal stack I've been using. e On Wed, Oct 1, 2014 at 10:03 PM, Sander Elias <[email protected]> wrote: > Hi Eric, > > You might be interested in this: > https://www.youtube.com/watch?v=3ZLlRQJp5Fg > Not angular, but on subject! > > -- > 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.
