Cool! I had seen that and I’m glad to hear someone’s working on it. Webpack has enough other advantages that I’ll probably keep using it though…
@jedwards Rocket:module is using Webpack behind the scenes. 
Let me know if there’s anything specific you’re doing with Webpack that might be something we can accommodate in rocket:module.
Oh! Is it running a webpack-dev-server? I like using react-hot-loader, sass-loader, and url-loader. I also had issues with google-map-react loading two copies of React that PrefetchPlugin somehow fixed (I still haven’t gotten to the bottom of that). And I figure who knows, the code splitting could come in handy someday.
So I’m curious how you’re using it exactly. I would have thought that a thin wrapper around webpack, exposing all webpack features, would have been easier than something that only exposes some. I’m also curious how you managed to get source maps from webpack into Meteor, because when I tried to make a package to pull in the webpack source map, Meteor crashed complaining that some things in the source map weren’t in the source.
thin wrapper around webpack
That’s in rocket:webpack, with plans to make it more flexible. It’s a matter of writing a small function that will _.merge a user config with the default config.
Meteor crashed complaining that some things in the source map weren’t in the source
Did you modify the isopack for the package that needed the sourcemap? There’s some stuff that needs to be done there if you’re not doing it via a plugin registered with Package.registerBuildPlugin. I haven’t taken care of that part yet, but yeah, I plan on passing the source map from Webpack to Meteor.
The thing with Webpack is that it uses a project-wide config (not package-specific like Browserify) so in order to make packages play well with each other, it’ll be difficult to let users specify what specific loaders they want to use. I’m think of letting packages/apps specify a list of loaders in a local file. I was previously allowing a local file (webpack.config.js) to contain settings for Webpack that were _.merged into the internal config.
Maybe the ideal use case would be to have rocket:module for packages, and for app code where not many configs are needed aside from the default, and make rocket:webpack more configurable, using a different filename/extension for a separate compile. The downside to that would be that dependencies and modules compiled with rocket:webpack won’t be shared with all the other stuff compiled with rocket:module.
1 Like
So if I want to use jsx and typescript together, file type would be .jsx or .ts?
Typescript doesn’t support JSX syntax natively but there are some projects that allow you to do it.
Your best option for this use case is to skip the Meteor build system and use something like webpack to package all of your code up and drop the resulting main.js file into the meteor/client/ folder.
There’s even have a tsx webpack loader here (loaders are transform plugins for webpack).
Using webpack with Meteor doesn’t work out of the box. However i’m working on a project with @jedwards that makes it really easy to do this!
The project is here Meteor-Webpack-React. However if you use this in the next few days I would use this branch as it will be merged in soon. It has a much easier project folder structure.
Article that may be helpful: Using JSX with Typscript
Let me know how it goes 
1 Like
Is there a preferred way to use this the other way around? As in, embed a blaze template into a react render function? I’ve come across this but I wonder if there should be a package to help with this.
1 Like
Yep! When you say embed, do you just mean to render it like below? There’s different variations of it out there but the important part is to deny any updates to the root container so that it won’t leak. Here’s what i’m using:
https://github.com/AdamBrodzinski/meteor-webpack-react/blob/minimal/app/components/BlazeTemplate.js
Then you can just do the following:
render() {
<header>
<BlazeTemplate template={Template.loginButtons} />
</header>
}
I should break this out into a package if there isn’t one already
3 Likes
I think that would make an awesome package. I would also suggest adding the ability to pass data to the Blaze component.
4 Likes
Yes exactly. It would be a great package to have. Thanks SkinnyGeek!
On a separate note, do you see this working well with autoform and simpleschema? I’ve worked with autoform before and like the ability to quickly throw up a form on a page and have the right dropdown values, validations, etc. I’ve read elsewhere here that there might be issues using autoform with React.
1 Like
Cool, i’ll work on this during my flight this weekend I just made a version that accepts a data context this week… just gotta polish it up.
I used it to create a React version of Tabular DataTables that lets you pass in React components for all the table controls (as well as the methods to update the table at your will).
Hoping to open-source that as well ! Have to see if my client will open-source it under her company.
In general it should work just fine to wrap any Blaze package as long as you’re ok with using Blaze as the rendering layer for that part of the component. Actually for example if you would use the template helper component that I haven’t released yet you could just do this for autoform:
<BlazeTemplate
render={Template.quickForm}
withData={{collection:"Books", id:"insertBookForm", type:"insert"}}
/>
instead of this
<template name="insertBookForm">
{{> quickForm collection="Books" id="insertBookForm" type="insert"}}
</template>
Take a look at this issue. Smooth integration is already happening:
It would be great to have these two in Meteor
1 Like
Awesome! it looks like it’ll hit 1.6 from this issue. Once that happens I imagine it will work with Meteor without any hacks like using webpack. You could then just load the react-data package for mixin support.
@SkinnyGeek1010 can you make DataTable tabular Blaze compatible or with some doc tips with @timbrandin sideburns , https://github.com/aldeed/meteor-tabular look like an abandoned project. Maybe is time to release a new one. DataTable is a very important package for Solo developers.
Thanks for your time and effort.
This package provides a a helper mixin called ‘ReactMeteorData’. does this work if we use es6 classes syntax to extent and use react instead of createClass()? Asking this since use of mixins are not allowed in es6. Same story goes with TS, Babel,…
You can use an adapter to basically ‘wrap’ the component with another component using the mixin. Something like this allows you to use
Posts = reactMixin.onClass(Posts, MyMixin)
However I tried to make my own higher order component a while back and there was a Tracker issue so i’m not sure if the above lib works with ReactMeteorData… worth a shot!
You can also just use createClass for components that use the mixin (I tend to make a PostsContainer that just handles data and then an ES6 Posts class that consumes the data… this makes re-use easier).
Once ES7 decorators settle, they’ll solve this problem.
So actually under the covers The ReactTabular is using aldeed’s meteor-tabular under the covers. Part of this reason is because we’re already using it and also don’t have time to re-write in pure React. Also I don’t think it’s abandoned but not actively adding new features. He’s open to accepting fixes. The 2nd to last commit was my PR to add support for modifying the query selector before publishing (allows you to do custom filtering).
Essentially it’s just hiding the stock DataTables controls UI and then calling the DataTables API to search/paginate, etc… If I can open source it and you need custom Blaze UI you can easily copy the React components to Blaze components (they’re pretty simple) and use the .
If I would would start completely from scratch I would go with FB’s FixedDataTable and then hookup a publish similar to meteor-tabular but more flexible (and easier to maintain!)
1 Like
I did not know FixedDataTable. Is good to have a DataTable alternative, but is not meteorized. I believe that meteor community is plagued of one-person shops and we need all automatized packages that we can have. On the frontend side all future proof packages must be render layer independet and all we have to put the effort to rewrite autoform , DataTable, FixedDataTable, …
Actually I read meteor forum everyday hoping of MDG include part of @aldeed invaluable code on the meteor core.
I see many stars last night and make a wish for one each of my prefered/needed packages.