search

jedwards1211 / meteor-webpack-react

(DEPRECATED) use jedwards1211/crater instead
https://github.com/jedwards1211/crater
374 stars 75 forks source link

Meteor specific issues #8

Open AdamBrodzinski opened 9 years ago

AdamBrodzinski commented 9 years ago

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.

grigio commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 :smile:

jedwards1211 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@tomitrescak branch created!

jedwards1211 commented 9 years ago

@AdamBrodzinski and your branch created too!

AdamBrodzinski commented 9 years ago

@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 :laughing: ). 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 commented 9 years ago

@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 commented 9 years ago

@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 :stuck_out_tongue_winking_eye: 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 commented 9 years ago

@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 commented 9 years ago

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

AdamBrodzinski commented 9 years ago

@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 commented 9 years ago

@AdamBrodzinski Things I didn't like:

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

tomitrescak commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

@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:

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 commented 9 years ago

@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 :smile:

tomitrescak commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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.