Meteor specific issues

[AdamBrodzinski]

I think it would be a good idea to keep track of known issues with Meteor compatibility for new users that come across this. I'll try to knock these off as I have time. Feel free to close if this is unwanted.

• Velocity tests must be placed (or symlinked) into meteor_core for them to run
• Can't hot-load Meteor methods or Mongo collections (force refresh required if that file changes)
• Must expose global for the meteor shell (can't require in REPL)
• No source maps on server debugger

[jedwards1211]

Do you mean react-router or is there something called reaktor router? And I assume you're talking about loading these libs through Meteor packages?
If you need to use React loaded via a Meteor package you can always make a script that exports React from whatever location the Meteor package puts it, and put the following in your Webpack config:

{
  resolve: {
    alias: {
      'react$': path.resolve(__dirname, 'getWindowReact.js'),
      'react/addons$': path.resolve(__dirname, 'getWindowReact.js'),
    }
  }
}

Only thing I don't remember is how to give the bundle access to the React variable, is it package scoped or does it get put in window.React?

[jedwards1211]

And yeah I wouldn't expect using FlowRouter with this setup to be easy, I wasn't going to even try going down a path like that, but definitely share your insights with everyone if you succeed.

[AdamBrodzinski]

Oh cool I might try out that later. It might be easier to just use the react package and resolve it like you mentioned. It just exports it to window.React on client and global.React on the server. Generally every Meteor package exposes one namespace unless they intentionally leak others.

Would this solve the issue of having a different dev/prod version of React? (I vaguely remember something about that being swapped in .prod). They take care of swapping out the dev/prod version when running meteor --production or meteor build.

Reaktor Router is a facade over FlowRouter that looks a lot like react-router, without the nested UI. However for this upcoming project the app is much more like spotify than 'pages' so i'm going to def. use react-router for that. I'll get FlowRouter working sooner or later 😄 It seems like it was looking for the / route before it was defined. I only spent 10 mins on it though.

So far very little issues. I'm going to setup Velocity testing today. I'm assuming the velocity tests will need to be put in the meteor folder because they ultimately need to be dropped into a specific tests/jasmine/integration/foo.js directory. Maybe fire up a 3rd webpack?... just kidding lol #yolo

I'm already using Karama outside of Meteor for React unit tests so that should just drop right in 👍

[jedwards1211]

Actually I'm going to just put this feature into the project right now (getting React via this alias)
I was mistaken about the prod React build thing -- one can build the prod version of React from the npm package by defining process.env.NODE_ENV to production and using UglifyJS. But making this skeleton automatically work with other Meteor packages would be good.

[AdamBrodzinski]

👍 Cool. I'm working on implementing Meteor settings into the build step too. They're working really well. It even does a full reload when the settings file change. Meteor settings is used for things like setting up S3 keys for dev and production or public keys for the client.

[jedwards1211]

Uhoh, bad news. So react-hot-loader requires react/lib/ReactMount, which ends up loading basically another copy of react, and it doesn't work with this aliasing scheme. So unfortunately using react-hot-loader together with the react-runtime meteor package is not recommended, and I won't be making this change. I will add a note in the README though. Personally, I'd rather not use any such meteor packages that don't fit neatly into the react/npm ecosystem.

[jedwards1211]

I decided I'll make a branch later that uses react-runtime and no react-hot-loader. That way people will have both styles available.

[AdamBrodzinski]

Ah, bummer. I don't think it'll be too big of a deal. The worst case scenario is you can fork the package and add an imply config so that it will just assume that React is loaded instead of pulling in a specific verison.

[AdamBrodzinski]

btw.. I think having the react-hot-loader should be the default one. What do you think? For me that was one of the biggest perks (my current prod app takes 8 seconds to do a reload 😦 ) I can also see how not having react-runtime will cause issues. My guess is people who are going to use this are ok with tinkering.

Just spitballing here but what if we create a Meteor package that does an NPM require for ReactMount, and exposes a global that we can resolve in webpack. We can set a debug flag so it's never used in prod (only dev mode).

It sounds like we couldn't do the above because any regular 'react' requires would use the NPM version instead right?

[jedwards1211]

@AdamBrodzinski wait a minute...I wasn't right about that at all! All we have to do is bridge in the other direction, sticking the React loaded by Webpack into window.React, then any Meteor packages can get it as they normally would. There's some kind of way to exclude the react-runtime package right? I'll have to look into it tomorrow.

[AdamBrodzinski]

Hmmm, you could leave out the runtime and just include the mixin and that would work for anything that the user creates. However if another packages requires react or reactjs:react without a weak dep. then it will pull in another copy regardless.

If we could make a Meteor package that just pulls in ReactMount then we could use react and avoid the Meteor packages pulling in a 2nd copy without the user knowing. It would be kind of a pain to keep it synced but I think it might be the lesser of two evils?

Also i'm not sure if this is the same ReactMount but there's a separate one on NPM https://www.npmjs.com/package/react-mount that might be useable to alias/resolve react/lib/ReactMount to react-mount?

At any rate the developer experience will be 100x better if we can figure out how to use the Meteor React package. It's not a big deal to me but I can foresee people getting confused and frustrated.

[jedwards1211]

Unfortunately that react-mount isn't the same thing. I think it's possible to put forks of the react and reactjs:react packages into the project that don't actually bring in the React library, and then any packages that depend on those will just use the local versions, so it should be frictionless.

Think about what a problem it is that a lot of Meteor packages were created solely to pull in some 3rd-party library, and in this case there are two incompatible ones doing the same thing that other packages might depend on. I'm really hoping Meteor eventually turns into something you just npm install, so that all 3rd-party Meteor packages just depend on Meteor and React or whatever else in their package.json.

I think we should just accept that there will be a bit of confusion and frustration when making a Frankenstein of tools like this -- to me it's still less frustration than trying to use React the way Meteor Development Group wants us to :)

[AdamBrodzinski]

I think we should just accept that there will be a bit of confusion and frustration when making a Frankenstein of tools like this

Agreed! I look at it like a fussy Lamborghini... it doesn't always run the way you want and the trim may fall off but once it's running it's an animal 😆

I'm really hoping Meteor eventually turns into something you just npm install, so that all 3rd-party Meteor packages just depend on Meteor and React or whatever else in their package.json

Yep same here. I'm hoping that when they do release ES6 modules it's going to be based on strictly NPM. I wouldn't mind the current atmosphere/packaging system to be deprecated. IMHO you could have all new > 1.3 packages be NPM, older legacy packages could still load in globally as they do today and when 2.0 rolls around remove the deprecated global packaging.

At any rate once we get these smoothed out i'll get some of the core devs to have a serious look at this since it can be used as a sandbox/strawman for the future Meteor ES6 modules.

[grigio]

Also wrapping any npm & deps is frankenstain.. I hope mdg and community will agree in a structure like this asap

[jedwards1211]

Cool, I'm glad to hear you guys share my concerns. I'm sure a lot of MDG insiders have been thinking about this for awhile too. Sometimes I thought that since (as far as I've heard?) Meteor is backed by venture capital, they're using the package system to get people locked into their ecocsystem kind of like Microsoft does, but probably they're wiser than that.

[grigio]

No, I don't want to think bad things about MDG, simply they wanted to guarantee a fullstack experience and are trying to do a smooth migration path, but now the ES2015 (and beyond) community is too strong and mantaining the Meteor platform "as is" is just slowing down the adoption of what is cool outside of Meteor (DDP).

Interesting Matt Debergalis (MDG) interview https://www.youtube.com/watch?v=hA4sToBHkPs

[AdamBrodzinski]

Yea i think that their solution was great 4 years ago when it first came out and AMD was the only browser module system and Browserify was buggy at best. However now that NPM is being used for clientside JS, it makes more sense to switch.

[jedwards1211]

Wow, I didn't realize Meteor was 4 years old. Though that definitely explains the package structure.

[jedwards1211]

So as far as getting React from the Webpack bundle into Meteor, I just discovered that by cloning the react-runtime package into the meteor/packages folder and commenting out the lines in its package.js that actually load and export React, it won't load React even though I've added the react package to the project. I checked the Meteor compiled code as well as typing React into the browser console, and sure enough, it wasn't there. As far as I understand the local copy will always override the copy from the repository as long as it has the right version number, meaning we have a viable option for supporting any Meteor packages that depend on the react package.

There would still be some more work to make the React instance used in the Webpack bundles available to them though. The obstacle is that the client bundle is currently the very last thing that gets loaded, which means its React instance wouldn't be available for any Meteor packages when they're loaded.

The solution, I assume, would be:

• put React into a Webpack Commons Chunk (I haven't experimented with Commons Chunks yet)
• symlink the Commons Chunk into the local react-runtime fork and add it in package.js
• create another Webpack bundle to be symlinked into the local react-runtime fork that puts React from the Commons Chunk into a package global variable (basically just React = require('react/addons');). I think babel automatically adds 'use strict'; so we'd have to make sure that code is not babel transpiled.

[AdamBrodzinski]

Hmm interesting! I haven't had time to dive into chunks too much... I tried reading the docs and my eyes were glazing over without any concrete examples 😆

That plan sounds good to me. The only thing we'd want to double check is that if we fork the react package, all the other packages have to think it's the real react package, otherwise a dupe will be loaded. I think if it's named react and in the local packages it will use the local one first but i'm not sure.

I mean at the end of the day package authors _should_ be using weak dependancies for React so in my opinion it would be the package maintainer's fault.

If the above fork didn't work, if we could just figure out how to get the chunk to load before the packages and then as long as the packages use a weak dep, no copies of React will load. Then we don't even have to maintain a fork. If this would work a script could run to grep for react or reactjs:react to check for double copies every time you boot up.

so something like this?

react
meteor.stuff.js (including JSX package for packages to consume)
webpack.bundle.js

[jedwards1211]

It's the react-runtime package specifically that I'm forking, not react itself. I got it working, but I want to clean it up a bit before I push.

Heck, we could have the npm scripts insert the latest version of the real react-runtime package into our fork every time they get run!

[AdamBrodzinski]

Oh cool! 🍻

Should I hold off on pushing my PR with the different structure? I can have that ready tonight or I can push it later and update it if that helps.

[jedwards1211]

I'm trying to think. I put the version that loads React from the Commons Chunk in a react-commons branch because it's a bit squirrely and I still consider it experimental.
Other than that, I figured out a few improvements to the run scripts while working on that (waiting for the webpack --watch bundles to be output before running meteor) that I want to port to the master branch. Should have that done in a moment though

[jedwards1211]

Okay, done with that. Yeah merge the master branch into your fork and then make a PR. I'll probably have to merge your changes into the react-commons branch manually.

[jedwards1211]

er...I'm not thinking, the changes from the master branch won't merge cleanly into your fork anyway. Would it be too much trouble to just make sure your fork has the latest versions of the webpack config files and run scripts, adapt the paths in them as necessary, and make sure the scripts all work?

[jedwards1211]

I've often wondered if there's a Webpack option to make it expose its require() so that you can use it in a REPL or browser console. I'll have to look into that

[AdamBrodzinski]

Would it be too much trouble to just make sure your fork has the latest versions of the webpack config files and run scripts, adapt the paths in them as necessary, and make sure the scripts all work?

Sounds good to me. I was also going to go over every commit to make sure I didn't miss anything too, so it should be up to date with master once I go over it. Then i'll add the karma stuff after that.

[jedwards1211]

Aha, this may be solution for the REPL! from http://webpack.github.io/docs/configuration.html:

target

• "node" Compile for usage in a node.js-like environment (use require to load chunks)

[AdamBrodzinski]

Wooooo nice!

[AdamBrodzinski]

Cool! Yea that should be fixed in the master of the upstream... Before it deleted the entire client folder instead of just the file.

[AdamBrodzinski]

@tomitrescak Ah I see the issue now. Commit 39d4d0 adds a gitignore with a glob which made the lib/configs.js file not get checked in.

It just had the following in it:

// Tell FR to wait until our ES6 code is fully initialized
FlowRouter.wait();

This is now updated here

Thanks!

[tomitrescak]

Been playing with it 14 hours straight ;) But finally got it where I want it, including typescript support (not through loader though as I prefer to compile it in atom). FYI, for typescript all you have to do it to rename jsx to tsx and use following notation:

import * as React from "react";

interface Props {
  foo?: string;
}

interface State {
  bar: string;
}

// React.Component<Props,State>
class MyComponent extends React.Component<Props, State> {
    render() {
        return <span>{this.props.foo}</span>
    }
}

export default MyComponent;

Also to support Semantic UI or Bootstrap a file-loader had to be added with a following configuration

{
  test: /(\.png|\.gif|\.eot|\.svg|\.woff|\.ttf)/, // we need this to load fonts
  loader: 'file'
}

But that's just info for other noobies like me ;)

If you'll ever need I can prepare a typescript supported version for you (with typings).

[grigio]

Sorry for the OT. I'm using with this project Cerebral and cerebral-router and it works fine, it also support pinterest-style routing.
Does FlowRouter also support Server Side Rendering with meteor-webpack-react?

[jedwards1211]

@AdamBrodzinski I think you can rewrite that require as import {template as AppPage} from './App.html'.

@tomitrescak I've seen this loader config for supporting bootstrap that I got from someone else and have used in all my projects without investigating more deeply if it's necessary:

      { test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192' },
      { test: /\.woff\d?(\?v=\d+\.\d+\.\d+)?$/, loader: "url?limit=10000&minetype=application/font-woff" },
      { test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/, loader: "url?limit=10000&minetype=application/octet-stream" },
      { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, loader: "file" },
      { test: /\.svg(\?v=\d+\.\d+\.\d+)?$/, loader: "url?limit=10000&minetype=image/svg+xml" }

[AdamBrodzinski]

@grigio

Sorry for the OT. I'm using with this project Cerebral and cerebral-router and it works fine, it also support pinterest-style routing.

Cool!

Does FlowRouter also support Server Side Rendering with meteor-webpack-react?

I think so. I haven't tried it yet since it's not quite stable. I'm super interested in send data down part.

@tomitrescak

If you'll ever need I can prepare a typescript supported version for you (with typings).

That would be cool! The type defs always confuse me lol. If you compile with webpack you also get hot module loading (not an entire page refresh)... not sure if the atom one will do that.

I also forgot to pull the react-transform from the blaze fork/branch.... that's not being used if there's no React.

@jedwards1211 cool I'll have to try that! I need to dig into the complete module syntax 😄

[jedwards1211]

@AdamBrodzinski @tomitrescak if you guys want to PR anything like this to be a different branch, just let me know and I'll create a branch for it (I don't know if there's any easier way to do this with PRs?)

[AdamBrodzinski]

@jedwards1211 cool, if you could create a blaze branch i'll cleanup the fork and PR. Just have to take a bit of react stuff out of it.

[tomitrescak]

@AdamBrodzinski the typescript loader from webpack seems to be having issues with .tsx file (typescript rich jsx) and it is giving all kind of errors, atom-typescript allready has a full support for it. The hot code reload still works flawlessly, since I made ts, and tsx being ignored by webpack and compile it to js and jsx into dist folder. The main.client.js and main.server.js are referencing those in the dist folder, so for webpack the situation is just like with regular setup. I will definitelly investigate how to do the "loader" way. But for now, it is fully functional and working very well with all the goodies of this great solution ;)

You do not have to use the dist folder altogether, but I do not like to mix tx and js in the same folder.

@jedwards1211 please prepare a Typescript branch for me and I'll prepare a typescript PR.

[tomitrescak]

@AdamBrodzinski just letting you know that I made the typescript loader work, but it breaks the hot code reload functionality. I guess the problem is with compilation chaining, where loader is specified as following:

{
  test: /\.tsx?$/,
  loader: 'babel!ts-loader'
}

After a module is modified, I always receive message on client requesting full page reload. Using extrenal compiler (such as the one in atom), make everything work silky smooth Zohan style ;)

[jedwards1211]

I just began working on another Meteor/React tool you guys might find useful. Check it out!
https://github.com/jedwards1211/meteor-seamless-immutable-cursor

[jedwards1211]

@tomitrescak branch created!

[jedwards1211]

@AdamBrodzinski and your branch created too!

[AdamBrodzinski]

@jedwards1211 Wooooo that looks really nice! I didn't even know about seamless-immutable. This just made my day!! (that's kind of sad actually 😆 ). Having immutable collections would be ideal! Have you used seamless-immutable before? Looks nice!

rtfeldman is the Elm guy... too cool (really good JavaScript Jabber podcast on Elm if you're into that)

@AdamBrodzinski and your branch created too!

Cool, thanks! Do you know if you're going to merge PRs #36 #37 #38 ? if not I should prob. take those out of the Blaze fork so they're congruent

[AdamBrodzinski]

@tomitrescak

just letting you know that I made the typescript loader work, but it breaks the hot code reload functionality. I guess the problem is with compilation chaining, where loader is specified as following:

Ahhh I wonder if it has something to do with react-transform and jsx. It's now using babel transforms. Did you try one of these loaders? These seem to be the most popular. Taking out (this) and trying these loaders may give you the hot module patching if that's preferred.

https://www.npmjs.com/package/typescript-loader
https://www.npmjs.com/package/awesome-typescript-loader

[jedwards1211]

@AdamBrodzinski I just converted my work project from Immutable.js to seamless-immutable and it's pretty nice. It's a bit rough around the edges and lacks some basic conveniences that Immutable.js has, and I almost want to fork it 😜 but it is more seamless than Immutable.js. With that and my new seamless immutable cursor thing, writing this frontend is going to be a breeze!

[jedwards1211]

@AdamBrodzinski oh man nice, I didn't know react-transform was out yet. I'll get caught up on your PRs, I was on vacation for the past week. Thanks!

[jedwards1211]

@AdamBrodzinski so I changed my mind about seamless-immutable...I'm making an Immutable.js version of my cursor thing instead

[AdamBrodzinski]

@AdamBrodzinski so I changed my mind about seamless-immutable...I'm making an Immutable.js version of my cursor thing instead

Oh bummer, is there a reason to switching to Immuable js? The seamless one seemed so nice I was planning on using in my ReactNative project. Were there any deal breakers (outside of the mongo project)?

[jedwards1211]

@AdamBrodzinski Things I didn't like:

• methods like asMutable etc. get stuck on every single immutable object, instead of being put in a prototype
• no convenience mutation methods like set, update, etc. Immutable.js's setIn can be especially nice.
• It tries to immutablize objects with custom prototypes. This caused problems, for instance if I tried to map an immutable to React elements, it would stack overflow when trying to immutablize the React elements.
• Immutable.js claims to have smart performance and memory usage due to using hash array-mapped trees. I don't really know enough to judge, but I'm assuming it's more scalable
• It has the look of a more one-off, not-actively-maintained project

Here's the new project, I've been tweaking it all day: https://github.com/mindfront/meteor-immutable-observer

[tomitrescak]

Guys, I am still discovering the full extent of using typescript and some changes had to take place so I'll probably put it together during the weekend.

I have one question though: Do you think it is a good idea to pack all CSS in the main HTML file? Semantic UI packs 450KB of CSS + ste CSS can come up all the way to 600-700KB, even with GZIP compression and others it still pumps quite a big chunk into the main file. Or does this happen only on DEV?

[AdamBrodzinski]

@jedwards1211 ah thanks for the info!

I have one question though: Do you think it is a good idea to pack all CSS in the main HTML file?

I think webpack does some analysis to determine if it's faster inline or as a sep. file request (heres a great video on that in general, To see if it does this in prod you can run ./prod and it should be the same as when you deploy. I haven't used to CSS loader though, only the Sass so far.

Also as a workaround you can place it in your meteor_core css directory and it will get bundled as normal there (or even add a CDN tag in the head in meteor_core).

[jedwards1211]

@tomitrescak Are you talking about Meteor pumping CSS into the HTML or Webpack? Webpack doesn't pump anything into the HTML file, when you use stylesheets with it they get put in the JS bundle and loaded by it somehow.

[AdamBrodzinski]

when you use stylesheets with it they get put in the JS bundle and loaded by it somehow.

Oh maybe I was thinking of webpack inlining base64 images instead of css.

[tomitrescak]

@AdamBrodzinski @jedwards1211 I'm talking about webpack pumping CSS into main HTML. It all rests in the head/style. But as suggested, putting it to the meteor-core directory should resolve the problem as meteor packs all css in one file, although I really liked the fact that webpack packed only used CSS and not all, significantly reducing the front end library cr@p.

I really like what you have done, having the possibility to debug JavaScript directly in the original .jsx files is like a dream. The only thing I did not fully comprehend is that debugger attaches at random. Placing breakpoint in the render and reloading the page many times misses the breakpoint, but then I do some other operations and then it picks up. Events and component helpers break always, that is great.

I have also decided to port our applications to React, I learnt that it keeps the project much cleaner and forces one to write more logically organised code. Also, the blaze templates do not work with your hot code reload.

[jedwards1211]

@tomitrescak oh, I forgot -- just to be perfectly clear here -- the webpack style-loader inlines the CSS in the JS bundle, and then somehow dynamically adds <style> tags to the <head>. So it's not loaded with the initial HTML, it's loaded with the JS bundle (which means if you want to get fancy with webpack code splitting you could load CSS in phases). As far as I know webpack-dev-server serves your index.html straight up like a static asset.

About debugging -- it's tough to tell, but I think these interfere with breakpoints:

• hot reloading
• debugTool: 'eval-source-map' etc., anything other than 'source-map'

And yeah naturally the Blaze templates wouldn't work with the hot code reload. Perhaps it would be possible to write some smarts into the React wrapper for them, but I'm not sure (probably it would have to require the template files directly instead of getting them via Meteor)

[AdamBrodzinski]

@tomitrescak

The only thing I did not fully comprehend is that debugger attaches at random. Placing breakpoint in the render and reloading the page many times misses the breakpoint, but then I do some other operations and then it picks up.

I've been having this problem in React native too (no webpack and perhaps exacerbated with async/await)... not sure if it's a babel specific problem. I tend to throw in debuggers if this happens. I think using a devTool sourcemap setting of eval makes it more accurate all the time but is ugly. I would also try source-map to see if that clears it up.

... although I really liked the fact that webpack packed only used CSS and not all, significantly reducing the front end library cr@p.

You might be able to load the base CSS in meteor_core and then use all of your hand-written stuff with the webpack css modules... a mix of both.

I have also decided to port our applications to React, I learnt that it keeps the project much cleaner and forces one to write more logically organised code.

Yea I've found that it's helped me a ton! It's kind of like how functional programming makes you think about the problem in small separate problems and then you compose them together. Regarding a re-factor... this video helped me quite a bit: https://www.youtube.com/watch?v=BF58ZJ1ZQxY

Also, the blaze templates do not work with your hot code reload.

I thought it should hot-load on a per module level, leaving the other blaze components in place.... can't remember off hand but I thought I could live edit html in chrome on blaze template A and then change blaze template B and then it would hot-load changes for just B leaving my local changes for A in chrome. I'll have to look into this more over the weekend 😄

[tomitrescak]

Thanks a lot for the explanation, makes sense! Concerning the video, makes a lot of sense, it's just a bit difficult to combine blaze with react, vice versa is doable. I did a PR for the typescript demo. Had to change some components and added some small bits to demo he differences, but I hope it is still in line with your demos. I still have to figure out the typescript loader so that it works with hote code reload.

My demo does not contain Flow Router, I can add it if you want. I had to extract the flow layout from arunoda as react is not available for meteor components. This brings me to my question. Where do you see this project after 1.2 when React will become part of the core? I guess nothing changes ... Still will be aweosme:)

[jedwards1211]

The reason hot-reloading blaze templates doesn't work is that nothing indicates that the <BlazeTemplate> module needs to be reloaded when a blaze template is changed. The only way I'm aware of to do that would be to have components that render <BlazeTemplate>s import the template HTML/JS files, so that it knows when they change. The problem is of course that this unnecessarily includes the template HTML/JS in the bundle. Maybe there's some way to do that and invoke spacebars via a React component instead of letting Meteor handle it by default, I don't know.

[sd031]

Hi ,

I am facing a very odd issue , after login using meteor account password package or any social login package I am calling Meteor.user() and getting user data , however if I go to other route after that , and calling Meteor.user() I am not getting any data , Please help I am total stuck here.