-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: caching #425
WIP: caching #425
Conversation
@EisenbergEffect, @bryanrsmith - here's a first pass at adding controller caching to the router/viewport Changes:
Non-obvious things worth additional thought/review:
Still working on:
Let me know what you think! |
The description makes sense to me. I'll try to review the code at a deeper level this week. @jdanyow We should try to get more eyes on this. Can you track down the other issue related to this and reference those people in? @cmichaelgraham Maybe you can take a look at this as well and see if it will handle your map rendering scenario. |
sure- here's some people from #173: @fopsdev, @jods4, @stefan505, @dpinart, @Scapal, @heruan, @Vaccano and from aurelia/templating-binding#95: @dkent600 |
Perfect. I'll do a technical review but hopefully the community members above can help validate that the real use cases are handled by this implementation. |
src/view-port-cache.js
Outdated
|
||
@transient() | ||
export class ViewPortCache { | ||
controllers = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember we had to ensure correct cache lookup by
controllers = Object.create(null);
I guess it's should be applied here also..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stoffeastrom - I can make that change. The issue solved by Object.create(null)
will not be an issue here due to the format of the keys but it's good to be consistent.
Will this caching be applied to everything contained in a view, including custom elements, manually-composed views, sub-routes, etc.? How will this interact with or be related to container options like |
@dkent600 good questions, it works like this: When a route is activated, the resulting view and view-model are cached. Subsequent activations of the same route (same fragment and querystring) will reuse the view and view-model instance. The view and view-model instance will not be unbound. The change in behavior requires opt-in via a property in the route config and does not interfere with resolvers like |
Will this play well with aurelia-validation (or vice-versa)? In other words, will cached views retain all of their validation state and remain independent of other views as if they were uncached? |
@dkent600 yep- unbind is what causes the validation errors, etc to unrender. Cached view+viewmodel pairs are not unbound, so the validation state will be preserved along with the rest of the state. |
Can't wait for this to be released! |
Amazing! Can't wait! @jdanyow keep up the good work! |
Should that be configurable? Like: maybe I want to reuse the same view whatever the query string is, and it might be taken into account during lifecycle events, most likely Is there a risk that the cache grows unboundedly? |
Side-note: if I understand correctly how this works, good communication/doc will be needed so that people understand clearly the difference in controls between Currently, when wrapping 3rd party library controls like jQuery plugins, I see people do their With the new view caching infrastructure, it is important to understand that Integrating a JS control with internal state (e.g. a Map viewer that has position and zoom) and showing how said state is preserved when switching views would be a nice proof of concept for view caching. |
export class ViewPortCache { | ||
controllers = Object.create(null); | ||
|
||
get(viewPortName, viewPortConfig, navigationInstruction) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should viewPortConfig
be the first argument, as the others can be ommited if viewPortConfig.cacheable
is false
.
@jods4 Great feedback! |
What's the status of this? My team is waiting impatiently! Really want this feature! |
@jods4 - I just wanted to reply to some of your questions from November 10th that I hadn't responded to:
The ViewPortCache has a createKey function that can be overridden to supply custom logic: import {ViewPortCache} from 'aurelia-router';
ViewPortCache.prototype.createKey = function(viewPortName, navigationInstruction): string {
const { fragment, queryString } = navigationInstruction;
return `ViewPort: '${viewPortName}'; Fragment: '${fragment}'; QueryString: '${queryString}';'`;
}
Yes and no- the caching will occur if the route's config has |
Will there be a way to clear the cache (selectively/everything)? So that you can insert some intelligence in what stays cached and what should be ejected from the cache depending on user actions. |
What I don't quite like with this design is that there is a central point where the rules for all the routes/views have to be coded.
That's what I was concerned about. I think this is a core scenario so:
I have not thought deeply about any of this, so I don't have any solution to propose. I'm just sayin'. |
My two cents: This proposed design (embedding caching config in a view) has the feel of angular to me. OK, not necessarily a bad thing, being like angular, but it seems to me like it would be making the view responsible for something not in its purvue. Ie, not one of the view's appropriate responsibilities. ("How does one navigate to a view" being outside of how a view does what it does.) As such, it would be stealing responsibility and knowledge from the routing configuration where all other knowledge about routes and navigation is currently contained. |
@dkent600 I don't know about Angular so there was no influence. I don't like spreading concerns all over the place, where it's hard to discover:
It is not clear to me that deciding whether a view supports/needs to be cached, what parameterization is required, whether its lifecycle must be called again or not is the view's responsibility or the caching infrastructure's. I would argue the former. As you can guess, I'm a little annoyed by the router as well and thinking of setting up some decorator-based routes configuration. ;) |
There's a couple of primary scenarios this PR aims to solve:
I'm sure there are many other scenarios however these are the ones I most commonly encountered in the discussions I've had and issues I've reviewed. I think we could add an option of putting the caching decision logic in the view-model to improve flexibility. |
Those really stand out as main use cases for me. Especially number 2. Not that the screen is necessarily "expensive" but might contains state outside of VM (like your example: inside a JS map control) and you want to preserve that state when navigating back. That said, I also think that good API design needs to think of what some users will invariably try to do and at least avoid obviously bad outcome. To avoid complexity and ship something, maybe in a first approach we could say that caching is done by route name only? @dkent600 mentions Angular, what is their approach to the memory leak problem? |
Guys ? @jods4 @jdanyow @dkent600 @gheoan @EisenbergEffect c/c @jwx @Darkless012 |
Any updates? This is still the no #1 requested feature from me, my team and our clients! |
Same here +1 |
Same here. I've ended up using store.js for now
… On 15 Jul 2017, at 15:39, Rico Suter ***@***.***> wrote:
Same here +1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Any updates? I want news from anything. |
This feature was originally being funded by a company who needed it. However, they decided that they wanted us to focus our efforts elsewhere, so the work on this petered out. @jdanyow may be able to provide some information on what work is still required to bring this to production quality. It's a tricky problem to do this in a generic way. I'm not sure if Jeremy was able to address those issues or if there were still open questions. |
requires aurelia/templating-router#42
fixes: #173