Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

fix($templateRequest): cache downloaded templates as strings #10646

Closed

Conversation

pkozlowski-opensource
Copy link
Member

Fixes #10630

brycehanscomb and others added 2 commits January 4, 2015 13:13
This is a functional workaround for babel/babel#376
And makes the comment code-style more consistent with line 143 and line 463.
@caitp
Copy link
Contributor

caitp commented Jan 5, 2015

FWIW I don't think this is the right fix at all =)

@caitp
Copy link
Contributor

caitp commented Jan 5, 2015

@pkozlowski-opensource lets just add a method to $templateCache like getTemplate() or something, which will dig the string out of the response array.

@pkozlowski-opensource
Copy link
Member Author

@caitp I'm also not happy about how this code looks like but I think it is less evil than adding new API and duplicating logic from $http. Actually I was really surprised to see that we've got those checks for an array / string inside $http...

I don't feel strongly about this fix at all (I think it is kind of corner case) but I think that it does what most people would expect...

@caitp
Copy link
Contributor

caitp commented Jan 5, 2015

If you don't want to add a new function, then I think we should change the approach taken by $http and store the "full response" cache in a different place somehow.

@shahata
Copy link
Contributor

shahata commented Jan 6, 2015

The storing of the promise while the request is still pending should also be in this "different place" then... But what is this different place? A cache key with a special prefix that can't exist in url's? Sounds kinda hackish...

@caitp
Copy link
Contributor

caitp commented Jan 6, 2015

a different cache object. it would be best to use WeakMaps to map between http's internal cache and the used cache object, but it's not really an option unfortunately.

@pkozlowski-opensource
Copy link
Member Author

Soooooo... @caitp / @petebacondarwin / @shahata / whoever - could one of you guys make a call on this one? Funnily enough I had someone few days back who bumped into this one but the use-case was debatable and I agree that people shouldn't be just using $templateCache as a synchronous substitute of the API that is asynchronous by nature ($templateCache).

Personally I don't feel too strong about this one, let's just make some decision.

@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

@petebacondarwin
Copy link
Contributor

OK, so I think we should land this since clearly users are doing things this way. It is kind of reasonable to want to access the cached template from inside the then handler of $templateRequest since arguably at that point it should be there.

For the record, the $templateCache is not designed to be accessed directly. You should always go through the $templateRequest since this the way to ensure that you do get the template you want - for example, something you don't have control over in your app might clear the cache in the background.

We should merge this and add it as a lesson learned to be very careful about what appear to public APIs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Beginning with angular-1.3.6 $templateRequest does not populate $templateCache
8 participants