Useful Packages about guide HOT 21 CLOSED

Dumb collections seems pretty awesome as an escape hatch to scaling - if you find that a subscription is being slow I wonder how hard it would be to swap it out with one of these.

CollectionFS - I've never used it, I understand it's basically the way to go when doing file upload in Meteor? Are there any good alternatives we should take a look at as well?

Subs manager - I wonder how well this works with template subscriptions, and whether it's crucial for us to include it in the guide.

ongoworks/security - I'm interested in using the Security.can approach to things. Should investigate further. Also Meteor.runRestricted looks interesting!

I'm just mentioning the ones where there might be interesting discussions; some of them are quite obvious, like tap:i18n.

from guide.

Re file upload, I feel like maybe things like http://cloudinary.com/ that store your file on S3 are better?

And I think Subs Manager is really necessary for almost any Meteor app. Otherwise having to wait for subscriptions on every route change kinda makes using a single-page app pointless…

from guide.

space:ui
It's worth mentioning that while space:ui (about to be renamed to space:flux) integrates with the view layer, I wouldn't categorise it under 'Templates & Components' as the goal is to better manage state using a Store and provide an event bus for components to announce changes in the view layer. The Store is a model of some concept in the UI and the API it exposes is then reusable across multiple components in the view.

CollectionFS
One caveat with the current implementation is that it limits the ability to run multiple instances of the app due to the use of observers for triggering cleanup and file maintenance tasks. I worked on addressing this, but it's quite a big change since we're pushing the work into a mongo queue, and given the size of the current install base it needs a lot of review.

vsivsi:job-collection should also be somewhere on this list @SachaG :-)

from guide.

I would add https://atmospherejs.com/peerlibrary/reactive-publish to the Publications & Subscriptions section.

from guide.

@jagi added :)

from guide.

+1 for job-collection.

from guide.

Constellation should be added, as well as perhaps a separate section for development related packages.

https://atmospherejs.com/babrahams/constellation

from guide.

@stubailo SubsManager is pretty important in template level subs. And it works pretty well with it.
See: https://kadira.io/academy/meteor-routing-guide/content/subscriptions-and-data-management/using-subs-manager

from guide.

Flux architecture

https://github.com/worona/meteorflux/
Elegant solution for Flux architecture in Meteor, much simpler than space:flux

Reactive Dependency Injection

https://github.com/meteorflux/reactive-dependency/

from guide.

+1 for job-collection, I'm surprised not to see the officially recommended React and Angular packages listed here.

from guide.

I think it wouldn't be useful to list all of the official packages on here - they are already quite popular and don't need the promotion!

from guide.

I don't think the guide is the right place for this list of packages.

from guide.

Wasn't that the whole promise of the guide? To embrace the community and point beginners to common packages?

from guide.

Yes, but having a huge list of packages isn't very helpful. In fact, it might just cause people to get more confused that they have to learn all of these things to learn Meteor.

If someone wants to write thoughtful articles about these packages and when they should be used, I'd be on board with that.

One option to move forward here is to make sure all of these packages are listed here: https://github.com/Urigo/awesome-meteor and then put a link to that page somewhere in the Guide. But we can't afford to be curating a huge list of packages for every possible occasion.

from guide.

This guide really digressed into again just explaining mostly only core packages + iron router?

from guide.

That's not true - we have a whole host:

#180 (comment)

And that list is outdated, there's a bunch of testing-related ones as well.

Remember, the guide is not about recommending cool resources or packages. It's about asking the question of what people want to accomplish with Meteor, and giving them the tools to do that. If you think there's something people want to do in Meteor that the Guide doesn't explain, then by all means let's have that conversation!

from guide.

If you think there's something people want to do in Meteor that the Guide doesn't explain, then by all means let's have that conversation!

I will make one example I am very familiar with: Blaze Components. They are not mentioned in the guide, despite they being pretty useful. Why? Maybe because we want to describe mostly pure Meteor. But then there should be at least a list of "do you want to lean more" or "some of things presented here are encapsulated in this package" or "for good patterns available through this package", etc.

from guide.

and giving them the tools to do that

You probably agree that we should provide them with the best tools to do that. Not just a tool. So if community have some packages do to something better, that should be at least mentioned, no?

from guide.

Why? Maybe because we want to describe mostly pure Meteor.

I wouldn't say this is the case. I think it's more because we have analysis paralysis - should people use Blaze Components or ViewModel? Should people with Blaze apps be refactoring them to React, or Blaze Components? Does using Blaze components add too much stuff to learn? These are some of the questions I'm concerned about.

from guide.

So, I think it would be great to just have a section at the end (or beginning) of Blaze chapter saying something along the lines: "Many patterns presented in this chapter can be found encapsulated and abstracted in the following community packages: Blaze Components, ViewModel. Moreover, React provides an alternative rendering engine with way to create components as well."

And similarly at other chapters (like data models, astronomy, etc.).

from guide.

So what I am trying to say that lists of packages/references to community packages can be a middle ground. Instead of you having to make a decision, you just inform users where they can go on, if they want, and they decide on their own.

from guide.