Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Bug/Fix accessing parentData(?) when having empty data context #4797
You will find a working leaderboard example for this usecase at:
This works fine until you change
Without the dummy argument, the data context is not initialized and therefore you can not access it via
So my suggestion and patch checks always for the existing of a data context or will create an empty object.
changed the title
Blaze/Spacebars: Bug accessing parentData(?) when having empty data context
Jul 23, 2015
changed the title
Blaze/Spacebars: Bug/Fix accessing parentData(?) when having empty data context
Jul 28, 2015
Hi David ( @dgreensp )
The problem on storing it on template instance is, that you can't access those values from child templates via
If you have a look at the MeteorPad, there is this style stored in a parent template and each child template will get any reactive changes. We made this like having props in React.
But without the data context on parent it can't be done.
can be accessed be child like
but not when created with
Did you recognized that?
Indeed, people want to access ReactiveVars in parent templates all the time, and it is a shame we don't have a better official pattern for that. Most people walk up the "view" hierarchy for cases like this. See, e.g.: https://forums.meteor.com/t/access-parent-template-reactivevar-from-child-template/973/8 .
But isn't to have a data context on each Template a better way than to use additional (hacky) packages? If I read the official documentation I would expect that I may have access to that context everytime. Why do you think that this isn't a good solution?
With the patch
In your example, there are two data contexts. The outer one is established by
The template instance solution I linked to really is more elegant, because template instance objects are 1:1 with instantiations of templates, they stick around for the entire life of the template, and if you want to read a value from "up the chain" of templates, you can ask for the
Hope this helps. I'm aware that understanding the data context may be confusing.
Hi David @dgreensp
thanks for your long reply. I got your message how templates and data contexts are working, I may miss something but I do not think that this might break pretty much every Meteor app.
The patch will just create a data context only if there is none. That means at least only the first template in a chain will be affected by this patch if there was no data context given yet.
Lets say for an existing app
In this case only template leaderboard will get a data context attached but this does not change anything on relative numbering to parentData() for the later ones, or does it?
From my understanding, when there is once a data context this is used also for any given sub-templates and with the patch there would be nothing changed to this behavior. Am I wrong?
The problem you describe with relative numbering to the right context, you are correct. From my point of view this is something like already existing app design decisions for each developer.
At least I can agree that it would be best if something like the linked solution would be already available by an "official" API.
This PR changes more than that. It does the equivalent of replacing
It breaks the app that runs our unit tests, for one (as well as a bunch of unit tests).