Hopefully this is a simple question to answer, but I do a lot, I mean a LOT of Session setting based on boolean situations. So that means in the html I have a lot of {{#if thisIsTrue}} statements with {{else}} or just closing it {{/if}} and I just wanted to make sure that’s okay. I guess if I’m checking for a ton of booleans, might there be another way of going about it or am I doing the best approach anyway?
Thank you so much, and if I need to clarify, please let me know!
Clayton
That also includes a boolean when checking to see if Session.get actually equals anything, like if there’s an object present or anything at all.
I think most people would say never to use Session, unless you have no other resort. Similar to global variables.
You can scope reactiveVars to your template instances, so that they are automatically cleaned up when that template is destroyed.
You can also use Blaze’s {{#if}} and {{#each}} as an evaluation for ‘falsey’ values. Not a realistic implementation, but if you’re looping through an each and want to display something based on the existence of a key/value in the object:
{{#if lastName}}
<p class="some-style-for-first-and-last-name">{{firstName}} {{lastName}}</p>
{{else}}
<p class="some-style-for-only-first-name">{{firstName}}</p>
{{/if}}
are there performance issues regarding Sessions?
Just used a Session instance because I was too lazy to pass props through several React components.
I don’t think there is a performance concern. The bigger concern (IMO) is when your app grows to a size where you have pieces setting Session vars that you can’t track down.
Yeah, I understand. I always try to keep Session count to maybe 1 or 2 sessions, 3 max. If you use too many, you could have a lot of trouble.
I have a lot of things that need to be triggered or shown when certain interactions occur. How am I supposed to connect actions from one template with another template if I’m not using Sessions?
Switch to React 
I’ve come too far in this project, it’s quite complex, and I really don’t want to pick up a new front end framework dangit, I like me some Blaze.JS! 
I guess since my app is rocking it solid right now, I won’t worry about it going forward. I won’t break what’s not broken.
I feel you.
My previous app was in Blaze and I either used 1) ReactiveVars or 2) Sessions to make UI changes based on user interaction.
I guess my only piece of advice is to give unique names to each Session and make sure you write them down on Notepad or a paper you keep safe in your desk drawer. I always gave my Sessions cryptic code names and wrote them down, primarily because I don’t want someone to reverse engineer my app easily and because it reduces the chances of Sessions clashing.
Passing props in Blaze can definitely be tricky at times, and IMO depends largely on how you build your app. Scope a reactiveVar to a parent template, then pass it to child components and have the child components update the reactiveVar’s value is one way I handle it.
Okay, ignorance here… reverse engineer? Can you go into more details? I understand what reverse engineering means, but this concerns me as I have obviously missed a step somewhere and I need to quickly adjust settings.
You don’t have to do anything differently than what you’re doing now.
I just personally like to name my Methods and Sessions cryptically because it’s fairly easy to click on the console, open the JS file and see the names of the Methods and such and get an idea how your app functions and how you do X step or Y step. Using cryptic names kind of makes that impossible or very hard to do.
It’s just a personal preference.
Good freaking crap… just did this, yeah, um, cryptic time! I try and code self documenting, so I don’t have to deal with the cryptic confusion, but looks like I’m going to have to now! Thank you very much for making me aware of this. Are reactiveVar’s susceptible to this same thing?
Most likely, though I’m not too sure. But I like to obfuscate everything I do with my app for potential copy cats lol.
Yeah, it’s a pain in the ass to track it all, but if you write it all down or put it in a notepad on your computer, it’s a small price to pay for a little extra layer of obfuscation/security.
Agreed, absolutely agreed. Yeah I’ll be doing a find and replace for all the things this weekend.
Good luck. You should switch over to React for your next project (if you don’t mind learning a new framework).
Does it have these same types of problems though?
I have to say I disagree here.
To me, writing maintainable code is a much higher priority than security through obfuscation.
If you have sensitive, valuable algorithms, then those should be handled server-side. Otherwise, I think it would likely be easier to steal your idea by building it from scratch rather than working through the minified bundle that is made available client-side.
Also, the value of your product is less in the code and more in the execution, anyway.
Like with reactivity? Hell no.
With React, you never have to use Sessions or ReactiveVars. You use something called states, which is unique to each component, so there is no chance of these things clashing in the global namespace. Everything is confined to its own component. You also never have to use events the way you do with blaze. In each component (which is analogous to a Javascript constructor), you can set up its own methods that can run your events. I don’t know if it makes any sense, but it’s much better than the Blaze system.
React is basically almost exactly like writing pure JS code. No handlebars, nothing.