Side effects? about meteor-webpack-react

[jedwards1211]

Oh, you mean using browserify and webpack together with a Meteor project? I'm not sure exactly what kind of side effects you were imagining. I haven't run into any major snags yet...
I'm sure it's possible to load both servers with a shell script, I'm just so weak at shell scripting I haven't looked into it yet.

I've used your babel package for Meteor by the way, thanks a bunch!

[grigio]

I mean is possible to expose the packages present in webpack/packages.json to meteor server-side? e.g React?

Thanks to you to try grigio:babel now it is deprecated, more integrated solution is coming from MDG :)

[jedwards1211]

Possibly, though I assume you would have to put whatever you want from those packages in global variables so that Meteor code could access them.

Also, right now the webpack bundle loads after everything else, but you would have to make some bundles/chunks load before Meteor code that tries to use them.

But rather than exposing anything bundled by Webpack to other code in the Meteor folder, I'd rather just experiment with writing all of the server code to be bundled with webpack.

[AdamBrodzinski]

But rather than exposing anything bundled by Webpack to other code in the Meteor folder, I'd rather just experiment with writing all of the server code to be bundled with webpack.

Yea that would be interesting if you could write the server code in the 'webpack' directory and copy it over.

What if you had a tree like this?

TodoList
   .meteor (hidden)
   both/
      main app code (share as much as possible for SSR)
   server/
      only server scripts here
   package.json
   webpack.config.js
   ...

Also worth mentioning, in 1.2 there're going to release a package that will just export a static html file with no blaze... that might be helpful for this repo?

[jedwards1211]

Yeah, I'd like to incorporate that package in this too eventually. I haven't had the need to try out SSR yet either, though that's a whole beast unto itself...I've seen some rather complicated isomorphic React/Webpack configs.

[AdamBrodzinski]

I haven't had the need to try out SSR yet either, though that's a whole beast unto itself...I've seen some rather complicated isomorphic React/Webpack configs.

Yeah agreed. However it seems like it's not too bad with FlowRouter and Meteor's if (Meteor.isServer) blocks. Basically you can do something like this in the component:

getMeteorData() {
  if (Meteor.isServer) {
   return { usersList: Users.find({}, {limit: 5}).fetch() }
  } else {
    return { usersList: Users.find({}).fetch() };
  }  
}

However i'm using flux now so it's going to be an additional challenge to hydrate the stores on the client. @arunoda is working on SSR for React as we speak! 😄

[grigio]

@AdamBrodzinski I'm not sure your snippet is a good idea probably would be better a solution like:

getMeteorData() {
  if (Meteor.isClient) {
    // subscribe at `component` or `router` level to any data the server decide to publish
    return { usersList: Users.find({}).fetch() };
  }  
}

and in a separate file in server/components/something.js

import 'something' from 'both/components/something.js'
...
// override the function with server-side specific fetching
getMeteorData() {
  return { usersList: Users.find({approved:true}, {limit: 5}).fetch() }
}

[AdamBrodzinski]

@grigio yea you may be correct... I haven't had a chance to play around with the SSR examples yet. having if/else seems less than ideal.

@jedwards1211 I'm just kicking around ideas but would this directory structure work if you could also copy server code as well (no SSR)? This kind of hides the meteor folder which is kind of a detail since you're not really using it much? I dunno perhaps making it hidden is too cumbersome for installing meteor packages.

At any rate i'm looking forward to setting it up on a pet project this weekend!

TodoList
   .meteor (hidden)
   client/
      main app code
   server/
      transfer server only scripts here
   package.json
   webpack.config.js
   ...

[jedwards1211]

@AdamBrodzinski I had actually experimented with a directory structure like that before (where you run meteor out of the root folder) but I found it kind of annoying because unless I hid the source folders for the webpack bundle, Meteor would automatically try to pull in that code (and hiding the source folders works but I just preferred to keep things visible by default). I thought new meteor projects have the .meteor folder hidden anyway so scripts in it don't get pulled in by meteor leading to a hard-drive exploding self-referential loop :)
As far as managing server, client, and shared code with Webpack, probably all you have to do is modify your webpack.config.js so that two entry points are created, one for client, and one for server, and then output these bundles into client and server folders for Meteor. Both bundles could of course require/import shared code from some other directory.

[jedwards1211]

If I have time in the next few weeks I'll move the server code into a Webpack bundle. And If I could actually manage to set up SSR, it would be really cool.

[jedwards1211]

Hmmm. I started testing out building the server code with Webpack, as well as having a both folder where things like collection declarations go.

However, having new Meteor.Collection(...) in a Webpack bundle doesn't work with hot reloading, because when it runs the new module, creating the collection again with the same name errors out. This isn't a problem with Meteor of course because it refreshes the entire page.

So this kind of seems like a snag. Also as far as debugging server code goes, I don't know if there's any way for Node to process the source map generated by Webpack. Maybe we should check out joe's new ES6 module plugin for the server side?

[AdamBrodzinski]

Oh interesting... Is it possible to have an ignored file for hot code reload? I can't find anything in the docs yet but if we can, then placing all the collections in an ignored 'collections' file could work.

The collection reload the only part of Meteor that I can think of that can't be reloaded (it's the foo/insert is already defined error?).

[jedwards1211]

Does consider this "issue" resolved?

[AdamBrodzinski]

I don't really see any side effects, just a few blockers. These are being gathered up in #8 in the checklist. I think this is resolved.

[grigio]

Maybe an OT here, @AdamBrodzinski did you try to load https://github.com/AdamBrodzinski/meteor-flux-helpers as an npm package (for Meteor) instead of Meteor package ?

If if works, newer Meteor packages can already be npm packages, just with meteor-component tag. The same tecnique used by http://react-components.com which are just npm packages tagged react-component

[AdamBrodzinski]

@grigio Ha! I was just thinking about the exact thing yesterday 😆 react-parts also does the same thing. Going to add that later today/this week.

I'm also going to publish all of my own Meteor packages there with the meteor tag. Speaking of... would meteor-module work better since some things are not "components"? I think components works for React since they're just the view layer.

Also side issue... in the hypothetical world that this would actually happen, how would we go about solving the minimum Meteor version and Meteor deps ('check', 'tracker', etc..)? I supposed since the entire build tool is built using NPM/CommonJS it wouldn't be that hard for them to convert to NPM modules?

example:
https://github.com/aldeed/meteor-tabular/blob/master/package.js#L12

Bonus points... using NPM modules you can share code via modules privately with your team using NPM's private service!

[grigio]

Why not meteor-package tag :P ?
I tested an example package with npm install ./my-package or npm link ./my-package and the "Meteor" global namespace is available.. of course you can't depend, example, on the reactive-var package in the npm package and the global ReactiveVar must be available already when the npm package is loaded.

An hacky way could be to throw errors or check the Meteor version at runtime..

if (typeof ReactiveVar === "undefined") throw("plz run `meteor add reactive-var`");

Probably they don't want to indroduce breaking changes before the Galaxy launch :P

I think Meteor 1.2 will include the cool stuff via ecmascript and browserify meteor packages and Meteor 1.3 probably will be splitted in several npm packages. But I'd prefere this approch than not depend on a lot of wrapper packages.

[AdamBrodzinski]

Ah, meteor-package would be better 😆

Yea throwing errors would be the best solution for now I think. I hope the resolve the hacky browserify in 1.2... it's kind of weird right now.

I agree with the wrapper packages.... nothing worse than 10 versions of Moment.js with varying versions.

Do you know how the new NPM 3.0 is going to work? I just started looking into it and it seems they're making browsers a first class citizen.

[jedwards1211]

@AdamBrodzinski huh, I haven't even heard about NPM 3.0 yet. Sounds interesting! Although I'm wondering what more needs to be done...Webpack seems ideal already!

I was just playing around with Webpack optimize plugins, and I'm guessing that will remain cutting edge even after browsers have native support for ES6 import, because not only can you reduce the number of separate bundles the browser has to request; it can also aggressively merge chunks, which I think means eliminating the overhead of using __webpack_require__ inside the bundle in some cases...

[jedwards1211]

I'll go ahead and close this but feel free to continue this discussion

[AdamBrodzinski]

Yea NPM 3 looks pretty cool! Checkout this:

• Checkout http://dailyjs.com/2015/06/26/npm-3/

This shifts the responsibility for fulfilling peer dependencies from library framework / plugin maintainers to application authors, and is intended to get users out of the dependency hell caused by conflicting peerDependency constraints. npm's job is to keep you out of dependency hell, not put you in it.

This sounds like it would be ideal for front-end because you don't want 5 copies of Bootstrap or MomentJS. I think you're right, even after ES6 modules are native you'll still need a loader and webpack.

[grigio]

Yes, and this is another reason why meteor package system exists.
But integrate high level external components will alwais be a pain without coordination among projects