"Todos" app madness (-:

setTimeout used in this context feels like a hack (or actually is a hack). Meteor.defer() sounds more like there is an official feature for such a use case. I agree there’s no big benefit, but the least is to decide on one way and stick to it both in docs and recommendations like guide or example apps.

1 Like

That’s a really interesting question. I always wondered what “magic” Meteor.defer() does over setTimeout()?

It uses node’s process.nextTick(funct) on the server, I think.

I put a pull request together for this. https://github.com/meteor/meteor/pull/6629

Maybe Meteor.defer should also be discussed in the Meteor Guide with common use cases for client (wait for dom update) and server (defer async function like send mail).

1 Like

setImmediate not nextTick!!! (nextTick is the most unhelpfully named function, it doesn’t do what you think).

/rant

1 Like

Yeah, sorry. My memory got confused by mixing it up with this incident: https://strongloop.com/strongblog/node-js-performance-meteor/

No that incident is exactly what I was obliquely talking about:

The workaround turned out to be surprisingly easy: after Meteor switched from process.nextTick() to setImmediate(), the problem went away entirely

@skirunman just saw the request being pushed and closed, thanks for the hard work! :slight_smile:

2 Likes

@skirunman is killing it with the PRs! So much good stuff.

1 Like

Thanks @sashko. You’ve got me through the end of this week :grin: and then back to focus on my SF based startup, Clozer.

1 Like

Is there a guide on complete Todos, as none of the books differ much from what’s covered in simple todos.

Nope, other than the Meteor Guide itself. It would be awesome if someone wrote an in-depth tutorial for the full Todos app though.

1 Like

If one of core appeals of react is that you get yourself ready to go components libraries that’s something that should be adressed in base tutorials as well <<. That thing where there must be a wrapper for react component and yet it has to be part of app.jsx structure for any data processing while meteor does ajax things for u.

Since it is the official example app for Meteor, someone from MDG is probably the most appropriate person to do that, ideally the main developer(s) of the app. I think there’s a lot of code in the app that a beginner would have no idea why it was done.

Also, the app seems quite bloated for what it does. I wouldn’t have expected a Todos app to have over 19000 files. Around 17000 of those files are under node_modules and just for eslint.

That’s just how npm works, surely you don’t also count all of the source code of Node.js and MongoDB as part of the app?

With so many files, deployment of this Todos app to IBM Bluemix environment fails.

Removing eslint, which is not a necessary part of the running of the app, cuts a lot of the bloat, down to around 2000 files. I’ve just tried it and deployment to IBM Bluemix now works without that bloat.

This sounds great in theory, but in realty this comes down to time, resources and ultimately money. I think MDG has down an awesome job putting the example app together, and lining it up with the Guide. They’ve also done an awesome job managing and accepting PR’s for Guide and Todos app changes, as a well as bringing in community members to help manage these projects. They’ve completely empowered the community to work on these projects, which allows them to continue working on other great Meteor/Apollo stuff.

In the end Meteor Development Group Inc. is a private company that needs to be (eventually) profitable, to keep the lights on. If we want them to continue to exist as a company and keep pumping out amazing stuff, we should throw in our support where we can. Sample apps, tutorials, documentation, tracking down bugs, etc., are all areas that have a much lower barrier to entry than say designing Apollo. It’s much easier for the community to jump into these areas, which helps MDG stay focused on the bigger picture.

3 Likes

Do a meteor npm prune --production before meteor build

1 Like

I added npm config set production before npm install to the buildpack script to avoid installation of the devDependencies that are specified in package.json.

All buildpack scripts should do npm config set production or npm install --production, but most (maybe all) whose code that I’ve seen don’t.

1 Like

That’s a great solution! Thanks for following up.