Recommendation Needed from Expert Here

#1

Hello all,

I need some recommendation here:

What I need:-

  1. Local client only (no server side code at all)
  2. Two Separate Browser Windows (one input data, one display data). I will use two monitor, one window on each monitor.

My questions:-

  1. What reactive data storage should I use? I tried Session and realise Session only valid for one browser window. Second browser window unable to read Session of first browser window.

Should I use MongoDB on client side only? Any other better data storage than local MongoDB?

Please advice, thank you.

Regards

#3

Do you mean you use two windows of the same browser on the same machine?

#4

Hi, the second browser window open from the first browser screen with target="_blank".

Same machine yes. Same Chrome browser yes. Just separate browser window at second monitor.

#5

I believe you can make this work with a package such as https://atmospherejs.com/cultofcoders/persistent-session

As far as I know without hitting the back end, a data source that gets written to localstorage is gonna be the only option for this.

#6

Hi, thanks for the recommendation. I havent try it yet. But if it’s working as Session, I believe it is still browser instance base. Which mean it doesn’t share the Session with other browser window’s instance.

Am I correct to assume that?

#7

You can use local storage.

  1. Values persist window and browser lifetimes.
  2. Values are shared across every window or tab running at the same origin.

If the package copleykj mentioned above use local storage then it works.

#8

Yes, it does: Modifies Meteor’s Session to store variables in the browser’s localStorage

#9

Thanks… I’ll try it now…

#10

When try use the recommended package, I got the following error at set Session with Session.set and Session.setPersistent, you guys don’t have this error?:

u2622_persistent-session.js?hash=57db38c11edeebc31dce68f5b5be8581c20a2286:265 Uncaught TypeError: Cannot read property 'apply' of undefined
    at ReactiveDict.PersistentSession.old_set (u2622_persistent-session.js?hash=57db38c11edeebc31dce68f5b5be8581c20a2286:265)
    at ReactiveDict._psSet [as set] (u2622_persistent-session.js?hash=57db38c11edeebc31dce68f5b5be8581c20a2286:285)
    at ReactiveDict._psSetPersistent [as setPersistent] (u2622_persistent-session.js?hash=57db38c11edeebc31dce68f5b5be8581c20a2286:383)
    at Object.submit .controlpanelForm (controlpanelUi.js:8)
    at blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:3818
    at Function.Template._withTemplateInstanceFunc (blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:3769)
    at Blaze.View.<anonymous> (blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:3817)
    at blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:2617
    at Object.Blaze._withCurrentView (blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:2271)
    at Blaze._DOMRange.<anonymous> (blaze.js?hash=cbd85c3fe14949f2d2b9a3b76334f5f0e96d553c:2616)
#11

Localstorage won’t be reactive. You could poll and diff against localstorage to look for updates on each side?

When I’ve had to do things like this, I just took advantage of Meteor’s built in reactivity and had them communicate over mongodb operations

#12

I think - since you’ve mentioned that you don’t want a server side roundtrip for tab/window communication, what you are looking for is the postMessage browser api which is event driven, therefore realtime, unlike localstorage which does not have an event system thus requiring polling.

I’ve used postMessage before for communicating between tabs, windows and frames and works quite well.

#13

Absolutely right that this package will not be reactive out of the box just because it uses localstorage; However it’s a very good starting point and only requires simple modifications to make it work. localstorage persists across browser tabs/windows and you can listen for the storage event to detect the changes.

#14

Oooh I didn’t know that it emits events!

It’s not mentioned in the localstorage or sessionstorage pages on MDN, but I found it on the Web Storage API page

#15

Yep!

I think the package could literally just listen for the event and then call set(event.key, event.newValue) on the internal reactive dict.

#16

Me neither and thanks a lot for pointing this out @coagmano @copleykj and it certainly is going to be something I will remember and use!

Yet, I still think localStorage is for “storing” information in the browser as the name impliies whereas the op is looking for a solution to send information from one tab/window to another, for which, the intended - and aptly named - api is postMessage.

Also, localStorage has storage limits that might require cleanup during long sessions of data transmission or simpli might not be able to transmit large chunks of data due to said limit. Incognito mode also adds more complexity to the behavior as it is not described in the spec and is implemented differently by vendors.

Furthermore, we have not yet even asked questions about the nature of the data to be transmitted. Is it sensitive? Is it okay to store and keep it on that device?

As for the reactivity of the data to allow propagating it to to the whole ui on the target window, yes a ReactiveDict (Session) sounds like a good approach to cary over and implement a global, reactive ui state store, especially (not necessarily exclusively, though) for a Blaze app.

#17

thanks guys… you guys are very helpful. very much appreciated.

#18

Personally, I’d just fire up meteor and use the local mongodb for your job. It certainly will do a nice job of persisting the info to disk long term. I would think the setup to be equivalent to hitting localstorage directly in terms of… time spent coding it up.
Having said all that, I’m just about to begin looking into storing a day worth of encrypted records using device storage… that will be an eye opener.

#19

I’m using GroundDb for this (https://atmospherejs.com/ground/db). Put simply, it gives you local-only, persistent, reactive data sources that you can interact with in exactly the same way as mongo/miniMongo. So find, findOne, update … all the same. It uses the best local storage engine it can find for persistence - i.e. indexeddb or if not available then localStorage. works beautifully.