Confused: Getting updates to non-collection data to child template

help
1

One of my app’s templates renders some elements on a canvas from parameters defined in a JSON object. I’m trying to refactor the template to “pass” the object into an included sub-component template, but struggling with how to do this reactively. In the “parent” template, all I had to do was catch UI events, mutate the object, then call my canvas-update function with it.

I’m also going to need to persist this object in a collection - users can make non-persistent edits, then hit a Save button to perform the collection update operation.

This object is not a reactive data source, so I started by trying to figure out how to tell the child template to re-render whenever object members have changed.

Do I need to replace my object with a reactive-dict that I can pass to the child template as an argument (in order to update the child template when it changes)? Then I have to glue the reactive-dict to the collection somewhere…

Am I going about this all-wrong? Should I instead be working top-down from the collection level object (which will contain my parameter object plus some metatdata like Title / created / updated) and just handing the child template the parameter object as its data context?

  • Designs collection
    ** Design
    *** Title
    *** Owner
    *** Metadata
    *** Paramters
<template name="ShowDesign"> <!-- Data context: Design -->
   {{Title}} by {{Owner}}
   {{> Preview (Parameters)}}
</template>

As you can see I’ve really got myself wrapped around the axle here over something pretty fundamental…

Thanks,
Dave

2

You could just put the object into a session or reactiveVar in the parent to make it reactive and then access it in the child template with currentData or parentData in the helpers. And indeed, in that case you’d need to separately push to object back to the database when the save button is pressed.

3

Thanks @vooteles for the tip… I didn’t realize you could store entire objects in a reactiveVar. (I’m a bare-metal C guy and JS is definitely a second language for me!)

After sleeping on it and thinking it through vis-a-vis “the Meteor Way”, I realized there’s no reason this data shouldn’t live in a collection right from the start. Currently refactoring from the top down to store the parameter object in a Designs collection.

When I think about it, this is exactly what optimistic UI is for! I can dispense with the Save button and persist all changes live as a bonus.

1 Like