Collection2 Future

packages
21

It’s great to discuss about the Meteor community packages and ideas for its future.

In my experience using Collection2, I have felt it a heavy piece, tightly linked with conventions like mandatory adoption of simple schema. I’ve faced challenges on the past with unsynchronized method interfaces compared to core Meteor expectations or performance impact, although it’s been a while since I used it, making it hard to provide specific examples. Likely the package has improved a lot. I also know that it has been crucial for many companies to adopt this package and its conventions, allowing them to focus on their products, which is the core concept of the Meteor framework.

Considering your proposed directions, I suggest keeping Collection2 as a separate entity maintained by the community. If it becomes more compact and loosely connected, embracing ideas like detaching simple schema and opting for custom validators, it would capture my interest definitely.

I agree with your view that integrating this package and the proposed changes into the core would demand significant effort from a small core team. Since there are enough challenges on the core ahead already, such as modern bundlers, native experience enhancements, and performance, which surely are more important for eveyone using Meteor.

3 Likes
22

Thank you for chiming in, Nacho.

Considering your proposed directions, I suggest keeping Collection2 as a separate entity maintained by the community.

So, this means you oppose merging it with other packages, correct?

If it becomes more compact and loosely connected, embracing ideas like detaching simple schema and opting for custom validators, it would capture my interest definitely.

Decoupling it from simple-schema seems like the way to go forward yet I wanted to do this step only after figuring out what to do with the package.

1 Like
23

Do you mean merging Collection2 into the core? I believe that conversation has been deferred for any package, given the current focus on Meteor 3.x.

In my opinion, not the final decision or representing the core team’s stance, we should consider migrating packages that are sufficiently decoupled, lightweight, critical, widely used, and preferably easy to maintain in the short term. This could help alliviate the core team’s workload as they concentrate on other priorities such as bundler, native, performance enhancements, among others.
Simultaneously, the community can lead the evolution of concepts in different packages. At some point, considering moving them into the core could be considered, but it’s not always necessary. Recommendations can be made in the official docs, and maintenance can still be handled by the community or individuals.

Edit: Or by merging you refer to what you stated here, Collection2 Future - #19 by harry97

I think the direction can be to merge them as well. I am not too familiar with all these packages anymore, some I never use them, and others I found alternatives. But if merging them serves well to the users of these packages, and it simplifies setup and experience, I would say go for it. The concept can evolve and even simplified with merging them. And with a simple sight I can see these packages to act and expand over the same concepts of managing collections and data. Makes sense.

1 Like
24

I would love the option to use Collection 2 with Zod!

At the moment I’m duplicated all SimplSchema schemas with zod and that opens up potential for errors (as well as duplicating work).

25

Just to clarify things as many people here already mentioned big issues if C2 would get breaking changes. The perspectives of Meteor Community Packages is compatibility-first and @storyteller and I try to make things as non-breaking as possible unless we are forced to.

Currently the bigger issue is async computations in simple schema that would also have consequences to Collection 2 as the whole validation for Simple Schema would be async.

A simple example: a field is optional if user has a role x. A field with such computed optional property may then look like this:

isAllowed: {
  type: Boolean,
  optional: async () => {
    return !Roles.userIsInRole(Meteor.userId(), 'canDoThin', 'admins')
  }
}

* Please don’t pin me on the usecase for the above code

26

I created a new Pull Request that aims to decouple Collection2 from Simple Schema as an intermediary step in the Roadmap of Collection2.

Note it’s wip and rather a proof of concept right now. However, I think it’s a nice input to keep this discussion ongoing.

5 Likes