Chronological Thread 

< Chronological >      < Thread >

---

Hi!

So, how is it going on this topic, of migration of PeerLibrary to recent
Meteor version? I think we should do this soon. Before October's big
lunch (hopefully things will render faster with Blaze). Are you working
on this?

> One of the things that are a constant source of problems is the fact
> that Meteor used to encourage devs to store many things in global
> variables (like the Session). They are so easy to use! However, this
> makes it hard to cleanly implement things like two search queries
> (like an @-user-search in the comment box for example). Luckily, other
> people had similar problems [1,2].
> Meteor's solution are template UI's -- not pretty, but it works. On
> [3], we played around a little and found it quite okay to work with.

I think is nice, but I am not sure why you would use:

@templatedata = templatedata = new ReactiveDict()

Instead of:

@foo = new Variable "foo"

https://github.com/peerlibrary/meteor-variable

So why one level of indirection in between? I would just store reactive
variables directly into template instance.

> Would you guys think this is a design pattern that is appropriate for
> peerlibrary as well? The obvious benefits include a leaner and meaner
> Session variable.

So do have in mind that having things in Session variable has one
advantage: we can hot-push a code update and it is kept across the
reload. Can this be achieved with your approach as well? Can you hook
into the hot reload code to add more to it to store?

On the other hand, I am not sure how good is to hot reload code if one
is just entering content into the inbox field. :-) Does it reload then
as well?

So I think we should start using this instance templates now that they
are available (and that you can also access parent instances), but
should not try to stick too much things there. I think that we should be
mindful that there are multiple options available and we should pick the
best one for each situation:

- session variable
- reactive variables added to template instance
- having a local collection (client only) and store data there
- having normal file level or project level JavaScript variables
- having reactive file level or project level JavaScript variables
- storing things into URL (but probably we map that then to one of above)

One thing to keep in mind is that currently when PeerLibrary crashes, we
try to store the error to the server and we store the session state as
well, which is currently easy to do. If we will have a lot of state in
template variables, we might have to hook into that as well (or maybe we
can ignore it):

https://github.com/peerlibrary/peerlibrary/blob/development/client/lib/flashmessage.coffee#L112


Mitar

--
PeerLibrary, facilitating the global conversation on academic literature
https://peerlibrary.org/
http://blog.peerlibrary.org/
https://twitter.com/PeerLibrary

---

• Re: [PeerLibrary dev] UI._templateInstance() and data locality, Mitar, 10/06/2014

---

Archive powered by MHonArc 2.6.18.