Continuing the discussion from Blaze <==> React Refactor Paths?:
What do you mean by this? Which parts of Meteor could be implemented as middleware?
Continuing the discussion from Blaze <==> React Refactor Paths?:
What do you mean by this? Which parts of Meteor could be implemented as middleware?
Perhaps middleware isn’t the right word, my boss and I are only using Meteor for the DDP and Mongo integration, basically everything except Blaze. I wish I could use something else to generate my HTML file/package my frontend code, and require the meteor client-side data tools within that, instead of having Meteor wrapping everything. I’ve heard the same sentiments from others.
Oooh, very cool. I will look into that. Thanks for the link!
That project discusses various reasons in more detail than I have for using Meteor only for data management.
You can actually paste in just the packages you need in the packages file. This can be a bit cumbersome but can leave out the unwanted parts (it’s surprisingly modular, DDP is the only thing that doesn’t swap well). I think MDG is working on a static page package that leaves out Blaze that will ship with 1.2 Create a version of Meteor platform without Blaze by stubailo · Pull Request #18 · meteor/react-packages · GitHub
I’ve done something similar for a backend only meteor app and it worked out well. (Fibers is hard to give up once you’re used to it )
Cool, that sounds good. I’ll probably see if I can combine that with Asteroid soon.
@SkinnyGeek1010 @Sanjo I decided not to go with Asteroid, as its collection APIs don’t exactly match Meteor. But I’ve gotten most issues ironed out with my Webpack/React integration.
Nice! Do you have any public packages for the Webpack integration? I don’t know enough about it yet but it sounds really nice!
No, I figured out a different way to do it: have webpack-dev-server
serve its bundle(s) up on a different port, and then put <script src="http://localhost:9000/assets/bundle.js">
etc. for them in the root HTML file. I don’t think the source maps that webpack outputs are consumable by Meteor, because the source URLs all use this webpack://
protocol. I don’t actually know too much about what it’s doing there. Doing it this way also allowed me to use the react-hot-loader
to reload individual react components when I save changes (I’m not sure if/how hot reloading React components with the official Meteor/React packages works?)
Very cool! Once you have it ironed out it would be great to look at minimal working example/boilerplate repo!
Meteor currently does a full reload like live-reload so you lose all the state. They have a new reloader coming in 1.2 that’s supposed to speed it up so that may change.
Cool, I’ll see if I can port the sample-todos example sometime this week!
Hey this is pretty slick! Can’t wait to try it out more this weekend.