Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Do not use Session as it's Migrated across reloads #13

Open
RobertLowe opened this issue Feb 12, 2015 · 4 comments
Open

Do not use Session as it's Migrated across reloads #13

RobertLowe opened this issue Feb 12, 2015 · 4 comments

Comments

@RobertLowe
Copy link

Just ran into this.

https://github.com/Differential/polymer-demo/blob/master/client/init.coffee#L3

https://github.com/meteor/meteor/blob/devel/packages/session/session.js#L1
https://github.com/meteor/meteor/blob/devel/packages/reactive-dict/migration.js

ReactiveVars are not automatically migrated across hot code pushes, whereas Session state is.

http://docs.meteor.com/#/full/reactivevar
@RobertLowe RobertLowe changed the title Do not use Session as they are Migrated across reloads Do not use Session as it's Migrated across reloads Feb 12, 2015
@ryw
Copy link
Contributor

ryw commented Feb 12, 2015

Hi Robert - what bad behavior did you observe as a result of this?

On Feb 12, 2015, at 4:28 AM, Robert Lowe [email protected] wrote:

Just ran into this.

https://github.com/Differential/polymer-demo/blob/master/client/init.coffee#L3

https://github.com/meteor/meteor/blob/devel/packages/session/session.js#L1
https://github.com/meteor/meteor/blob/devel/packages/reactive-dict/migration.js

ReactiveVars are not automatically migrated across hot code pushes, whereas Session state is.

http://docs.meteor.com/#/full/reactivevar

—
Reply to this email directly or view it on GitHub.

@schnie schnie closed this as completed Feb 12, 2015
@schnie schnie reopened this Feb 12, 2015
@schnie
Copy link
Contributor

schnie commented Feb 12, 2015

Yea reactive var is probably a better way to do it. One of the issues that all this is attempting to fix could return. The goal of this little dance is to wait until polymer is ready before we even attempt to render our meteor templates via IR, which contain polymer elements. If polymer is not ready by the time they render, helpers and events on them could attempt to use polymer functionality on those elements before they have been upgraded. On a related note, we need to render IR to a child element due to an apparent incompatibility between some polymer interaction with the <body> tag and the way a default IR configuration uses blaze's event delegation. By default, Blaze delegates all events to the parent of the template the event map is defined on. IR overrides this behavior a bit by passing <body> as the parent element whenever it instantiates a new template instance, which delegates all events up to <body>. At some point, polymer seems to clobber this setup. By setting a child element as the root for IR we can avoid all that.

@rgoomar
Copy link
Contributor

rgoomar commented Feb 16, 2015

Reactive variables are being used now instead of Session which does make sense to me.

@RobertLowe
Copy link
Author

Yea, that's what I did in the application I'm working on. ReactiveVar ftw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ryw @RobertLowe @schnie @rgoomar