@arunoda save me from learn IronRouter. I owe him many hours of my life. I will like to owe many more hours to devman that write a good new form and/or table package …
aldeed:tabular is not abandoned. It works very well for 9 out of 10 cases, and I’ll have a new release soon that fixes known bugs for those other cases.
2 Likes
I laughed hard when I read the post that @SkinnyGeek1010 should rewrite some 3rd party package for free 
This is such bad habbit expecting to be granted everything for free.
Problem is that if we even have portal where u can pay ppl to port some 3rd party package/lib to meteor, they finish and probably not maintain regularly without more payments. Cause they are not forced to use their own packages, like for example kadira is doing - developing packages they use and opening them after that. But they are already kinda forced to work on them.
What would be needed to have successful portal like that?
How the github/package ownership would be maintained if we want to grant access to external ppl ?
All of them under 1 github account and these external paid ppl would just PR and we as maintainers merge it to new package version ?
Now when I am thinking about it.
It could work.
1 Like
Pete Hunt also uses this.data for his Minimongo cache implementation. I’m curious why as well but it might be because it gives them more control over when it will render? example:
https://github.com/petehunt/minimongo-cache#working-with-react3
Revisiting a very old thread here, but I finally took the time to look through the code of that minimongo-cache project, and a big difference I see is that he is providing support for this.data in shouldComponentUpdate() here.
If react-packages were to do that (I’m not seeing it), as well as support the other lifecycle methods with this.data, I wouldn’t feel so strongly that we shouldn’t be storing data in this.data. Though I still think the separation of data is overcomplicating things and you really shouldn’t overwrite core methods that React developers are used to. Unless of course you happen to be the original author with plans to change the core methods. 
Though the lack of recent commits makes me think that project was mostly experimental and not really a preview of where React will go in the future.
But as it is the controller-view pattern seems like the only reliable way to support the lifecycle methods and pureRenderMixin. If we’re sticking with storing data in this.data, the examples should really be written with controller-views so we don’t lead developers into confusing situations.
1 Like
Yea I think using a controller-view is a best practice anyhow. It certainly makes it easier to unit test it’s child component. I would be happy to refactor the examples sometime next week if that’s something MDG wanted. Unfortunately the examples tend to be a compromise between minimal code and real-world app code.
Providing a higher order component wrapper for this would eliminate the this.data confusion and allow for ES6 classes. Something like below?
let PostsList = React.createClass({
propTypes: {
posts: React.PropTypes.object,
isReady: React.PropTypes.bool,
increaseLimit: React.PropTypes.func,
},
render() {
return (
<div>
{this.props.posts.map(postDoc => {
<Post {...postDoc} />
});}
</div>
);
}
})
//
// wrap component with data wrapper
//
PostsList = Meteor.ReactData(PostsList, {
increaseLimit(limit = 5) {
this.limit = limit;
},
getMeteorData() {
const sub = Meteor.subscribe('posts', this.limit);
return {
isReady: sub.ready(),
posts: Posts.find().fetch(),
}
}
});
I started working on this but ran into some infinite loop issues or something with tracker... at any rate i'm using flux instead of side loading so I haven't had the time to figure out how to make the higher order component work. (i'm mostly using flux for overall app architecture not just for data loading)
@sashko have you guys played around with using the mixin with a wrapper component?
As the question raised here, the current cosmos:browserify approach slows down the build process significantly (e.g., my simple app including 5 npm modules takes at least 20 minutes to build) to the point it’s not practical to use it. Also it requires reference to absolute version / commit of npm modules for dependency definition, which makes it difficult to use modules on github which define chain of dependencies simply as author/module to refer to the latest version.
I look forward to seeing some significant improvement here soon. Thanks for all your great work.
1 Like
Wow that’s crazy! You may be interested in using this webpack boilerplate… you can use NPM modules and can require/import them like a normal JS app. Then it just drops the client and server bundles into the meteor folder for you. https://github.com/jedwards1211/meteor-webpack-react
It also has hot-loading so it can swap out/patch functions that changed so the entire app doesn’t have to force reload on every change.
Would you be able to send me your packages.json file so I can try it out with that setup? I’m curious to see what the build times are in comparison. I’ve been using this setup on my latest app and it’s working really nicely. It just doesn’t have server source maps in node-inspector (yet).
@SkinnyGeek1010 Here is my packages.json.
{
“exposify”: “0.4.3”,
“react-pixi”: “0.6.1”,
“radium”: “0.13.4”,
“material-ui”: “0.8.0”,
“react-masonry-component-4meteorhacks-npm”: “0.0.13”
}
Thanks!
1 Like
Just tried it (minus exposify) from an empty project the npm install takes 41 seconds on my machine, mostly for the webpack stuff. Once that’s done any additional builds take 10-12 seconds and any changes to a file will re-hot load around ~1.5 seconds. We’re trying to get the reload time down but it seems to be fairly constant on large projects too.
Also I just ran the latest and it has a breaking change… the scripts were moved and it errors. If you checkout commit 77c28c (prev one) and run npm run dev then it works just fine! We’ll have the script sorted soon. I have a long flight today so maybe i’ll PR. edit PR submitted
That sounds great. Is there a step by step instruction of how to use
meteor-webpack-react? The readme on the github site wasn’t easy to follow
for me.
That sounds great. Is there a step by step instruction of how to use meteor-webpack-react? The readme on the github site wasn’t easy to follow for me.
I want to write a guide this weekend and maybe a video tutorial. I’ve been really swamped the last week.
Doing an NPM install then running ./dev should be all that’s needed to get it going
searching for things like sass-loader will show you how to add a webpack loader to the current config
2 Likes
We are still waiting a guide and a video tutorial (-:
1 Like
Once I get the velocity tests working well I think it’ll be good to go. (currently the folders need to be manually symlinked into the meteor_core folder). I’m scheduling some time in this coming Sat.
3 Likes
Hot off the press!
How to use Webpack and ES6 Modules with Meteor
https://www.youtube.com/watch?v=QpixFzvf8U8
I apologize for the quality. I only had time to do one pass (no stopping!) and didn’t have time to edit out pauses, umms, smacks or to cut fluff. I’ll most likely re-record it when I have time 
Please let me know what doesn’t make sense or what I left out… re-watching it a bit I noticed I could have covered a few things better like hot-loading, client/server bundles, etc…
5 Likes
Very interesting!
But, in my opinion, in the simplicity and elegance of the Meteor added some unreal complexity…
Do not stop, we need more tutorials and videos for better understanding…I need (((((-:
1 Like
Yes, running your own built step will always make it more complicated. For some this extra complexity is worth it. For my latests projects it was worth it. However, Meteor core will always be the most simple solution!
is it still possible to build an app created with this to use cordova for ios/android, just as standard meteor build command does? i was wondering how much other functionality was possibly lost in this, or if there are just different methods to accomplish things like this… thanks for your efforts, the hot loading is really something we need.
1 Like
I haven’t tried but it should build the iOS and Android targets as well with the ./build script. I’ll try out this soon. No functionality should be lost… with the exception of not having an easy way to run the simulator (this would just need the run scripts to be edited).
The hot-loading prob. won’t work without changing the script. Perhaps taking an ios or android argument for the dev script would work in the future.
The only change needed (I think) would be to change:
meteor --settings ../settings/devel.json &
to
meteor run ios --settings ../settings/devel.json &
As a work around today you could run ./prod to run the app in production mode. This essentially creates two bundles and drops them into the meteor_core folder. Then you can kill the webpack watcher with ctrl-c.
Now in this state there are two bundles in the meteor folder and no watcher running. From here you should be able to do a ./met run ios to run it in the simulator. This wouldn’t hot load from within the simulator though since those bundles are not being watched for changes.
At any rate once I have time i’ll try to add some mobile helpers so it should be a one command operation to get it running on the simulator. It (should) have first class support for Cordova soon. I also need to support Electron shell soon so i’ll have a fork to support it at the least.
thanks for your efforts, the hot loading is really something we need.
It’s almost all @jedwards I just helped polish it up a bit and hammer out a few bugs on my end.
This is great news, I’ve seen there is a http://bit.ly/1NvEfjH, angular-meteor project.
I love the idea of using ReactJS as the frontend view
FYI the official React support was released in 1.2 and is now a core part of Meteor.
1 Like