"Todos" app madness (-:

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.