These are chat archives for reactioncommerce/reaction

2nd
Apr 2016
newsiberian
@newsiberian
Apr 02 2016 03:46

@jshimko, Jeremy, recently you leaved a comment about Tracker.Component. And this is quite interesting because yesterday I've started to think about switching from komposer to something else. Did you look at other tracker realization like currently MDG default and especially what do you think about TrackerReact?

The problem with komposer - it reruns on every props change which is terrible. I've noticed that just yesterday. How do you think other Tracker realizations also have such "side effect"?

Lukas Sägesser
@ScyDev
Apr 02 2016 15:32
@brianxcli Thanks. How did you replace it?
Jeremy Shimko
@jshimko
Apr 02 2016 16:03
@newsiberian I really only recently started researching the options for container composition with React/Meteor, so I unfortunately don’t feel like I have an informed opinion yet. However, I really like the simplicity of Tracker.Component. There’s very little code behind it (~50 lines), so it’s pretty easy to understand what’s going on at first glance. And setting up your data in components looks very similar to the old Blaze style template-level stuff in onCreated hooks (this.subscribe(), this.autorun(), etc.)
I really wanted to like react-komposer, but I just don’t care for the syntax at all. It’s not obvious what’s going on when you read the code for a container definition. And if it’s not performant on top of that, I don’t think I have any interest in using it. Also, a problem that both react-komposer and Meteor’s createContainer has is they are just one big autorun wrapper around potentially several reactive dependencies. So if any of those deps change, the entire thing runs again. Tracker.Component lets you define as many separate this.autorun’s as you want. So only the ones that change will re-run (at least that’s my understanding of it).
I don’t know if Tracker.Component is more efficient in general, but it certainly seems like that may be possible. I guess I need to do a little more digging through the source of each package so I can get a better idea of what’s really going on.
Illustrates the UI impact of lumping all reactivity into a single autorun vs isolating them like we did in Blaze.
Petr Juna
@creaux
Apr 02 2016 17:55
Hello, I tried to deploy on meteor.com using meteor deploy <subdomain>. Is that expected/supported?
Errors prevented deploying:
While linking the program:                    
error: reactioncommerce:reaction-logger is not compatible with architecture 'os.linux.x86_64'
Jeremy Shimko
@jshimko
Apr 02 2016 17:58
Are you a Galaxy customer? As far as I know, the free Meteor hosting was discontinued this week. (not really anything to do with the issue, but still relevant question)
Jeremy Shimko
@jshimko
Apr 02 2016 18:04
As for your actual issue, it’s because that package has a dependency with a binary that needs to be built for the architecture the app is being deployed on (64 bit Linux in this case). In a typcal manual deployment or a Docker build (using our Dockerfile), that should just work. But I don’t what Meteor has going on with their hosting and we don’t really have control over that.
For a little more info… https://github.com/meteor/meteor/wiki/Build-Machines
This is an internal package though, so it’s not really the same thing as publishing to Atmosphere (as discussed in that article).
For that reason (and several others), deploying Reaction with Docker is usually your best bet for guaranteed compatibility. It’s an isolated container with all of the dependencies that Meteor/Reaction needs and it reliably works the exact same way no matter where you deploy it.
I haven’t used it in a while, but MUP is a battle tested option as well.
https://github.com/arunoda/meteor-up
Petr Juna
@creaux
Apr 02 2016 18:09
Thanks for comprehensive answer. Just started with meteor and reactioncommerce itself two weeks ago so everything like this is very helpfull.