Side effects?

[grigio]

Nice, are there side effects with this approch with meteor, react, browserify on client or server side?
Is possible to load both servers with a single command?

[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?