Not working with 1.3-beta.x

[etmarch]

I apologize if this has already been answered, but will this app (or architecture in general) still be a valid approach with 1.3? I've tried to update this repo to all 4 betas of 1.3, but I just couldn't get them to build.

[yinghaochan]

@etmarch Sorry dude! I'm pretty sure 1.3 will need a new approach, and it will have a bunch of overlapping features.

Is there a feature from 1.3 that you really want? Have you tried 1.2.1 instead?

[etmarch]

No worries, thanks for providing this great example to the community. It's so painful going back to 13 second refresh times with 1.3, as opposed to nearly-instant times with webpack hot-reload!

In terms of whats important with 1.3, I've been developing my latest app with 1.3 and I'm loving the ease of npm module integration - no more wrapper packages from atmosphere, and now we have all of npm at our fingertips. I am also liking the /imports lazy loading of code, instead of the prior everything-gets-loaded-whenever paradigm.

Now that I think of it though, your app can do all of that and more, at its current state right? (*note: In case you can't tell, I am really unfamiliar with both webpack and browserify, although I am kind of aware of what they are capable of). How would you go about using an npm module in this app?

An issue I have with 1.3 so far is the inability to use babel for ES7 decorators and other ES6 class stuff, and apparently it wont be resolved until after 1.3 -- . However, in your current app it looks like you can pretty easily load the proper babel plugins via webpack, right?

I guess what I'm getting at here (and sorry for rambling - i've spent wayyy too much time worrying about stack) is a question for you: is there anything Meteor 1.3 adds that your current architecture can't?

[yinghaochan]

@etmarch Yeah, I made this because we have the same problem. Thought others could benefit from my weeks of pain, too.

Plugins are pretty easy to load, along with npm packages (especially client side). Just add the package to webpack.packages.json, and you can import it in any client folder. That's what I used to add Redux, too.

You still need to load server-side npm using the meteorhacks package.

It seems like a good fit with your requirements, though I'm not a huge fan of ES6 classes. Even the creators of React prefer to use React.createClass()... That should give you some indication.

I think we'll need to wait for 1.3's database options to see a majorly different feature from this. I'm, however, a little hesitant to use the meteor betas for a significant amount for dev because it's hard to track changes with all the magic happening.

Happy to help! Would love more feedback.

[etmarch]

Thank you for answering my questions. My only hesitation is the fact that I haven't used Redux yet, as I have been learning the basics of plain old React first. My app has finally reached the level of complexity that simply cant be maintained without a real state manager, so Redux it is.

Tomorrow I'll give your repo a clone and start to integrate my current components into this architecture. If you remember any clear difficulties or 'gotchas' when taking this approach, I am all ears!

Sidenote: I was under the impression that React.createClass() was being deprecated for ES6 classes, but I've heard arguments for both repeatedly.

[yinghaochan]

@etmarch It's easy to remove redux a few months later into your project by deleting ~10 lines.

However, I'd explore redux for these use-cases:

• If you eventually want to move off Meteor
• If there's a lot of client-side logic that you want to re-use
• If you don't want to thread props through a bunch of stuff, or maintain some local state though different routes.