Meteor 3.0 async frontend? (Minimongo, Tracker, etc.)

[marklynch]

@grubba

Hey!
For the front end, nothing will change, and the methods with their *Async counterpart should not be affected when 3.0 hits.
For the server, it was decided to remove the non-*Async methods, 3.0 using these methods will result throw an error

the current docs for preparing for Meteor 3 imply that the client also needs to migrate to async, which is mostly unnecessary and might mislead people in how difficult it would be to upgrade to Meteor 3

This is good news. I’m assuming it comes with the caveat that there’s no shared code touching async APIs in the mix?
So if I use minimongo in some frontend code it can remain unchanged? But if in my frontend I call some shared logic, that code will need to become async aware correct ? But I don’t see how this shared code can work - and less so how the migration path would look if on client its sync and on server it’s async. Apologies if this has been cleared up elsewhere but I’m confused

[alawi]

@marklynch

Apologies if this has been cleared up elsewhere but I’m confused

I share the same confusion. I’m assuming the main issue at the client is when using stubs and shared methods with the server?

[jam]

Yes, that’s the way I understand it.

For isomorphic code, you’ll need to write asynchronous code using the *Async suffix.

If you’re interacting with Minimongo on the client, you can write synchronous code. I think the most common example here would be using .find().fetch().

[marklynch]

So I’m guessing this will lead to a decision in many places where you either

a) Keep your code isomorphic and then have your frontend ‘infected’ with async
b) Make a client and server specific version of the code so you can keep your frontend sync.

[filipenevola]

@Alawi

extended security maintenance

Yes, that is what ESM meant in this thread.

[filipenevola]

@marklynch

So I’m guessing this will lead to a decision in many places where you either

a) Keep your code isomorphic and then have your frontend ‘infected’ with async
b) Make a client and server-specific version of the code so you can keep your frontend sync.

Yes, that is correct.

Many Meteor projects don’t share code; in these projects, the methods always run on the server only, so it’s important to make this distinction.

[marklynch]

Thanks for the confirmation Filipe
Thankfully we only run about 2 or 3 simulations, so our methods are 99% server only. But we do have plenty of logic that’s in common code and called by both sides. I’m guessing the simplest would be to go with b and just avoid sharing code that touches things like minimongo.

[waldgeist]

My biggest concern ist actually not my own code, although it will take a while to migrate it. My concern is the 3rd party packages I am using. A lot of their maintainers have left the ecosystem. I’m not sure if I will be able to patch these myself, and the list is pretty long.

Just as an idea: How about setting up a list of packages that have been forked and patched for 3.0, even if these forks might not be “official community packages” yet?

[illustreets]

I understand your concern. I have been wrestling with this issue as well. But, there are some good news here as well:

1. The Meteor Community Packages are rather well looked after. If you have a patch to contribute I’d suggest you do it there directly so everyone can benefit from it.
2. If it is a package that looks unmaintained, perhaps try and search for a recent fork and contribute to that one if it is not already updated. I was rather pleasantly surprised to find quite a few of these on GitHub.

Well, maybe this is the break that needed to happen. After all this, whatever packages have api.versionsFrom('3.0.0') are the ones to keep moving forward.

As a side note, this may also be a great opportunity to trim down the fat of external dependencies.

@waldgeist

Just as an idea: How about setting up a list of packages that have been forked and patched for 3.0, even if these forks might not be “official community packages” yet?

Both Atmosphere and Packosphere could do with an update to either filter or highlight the minimum Meteor version for each package version. The latter is the work of @copleykj, so I would imagine he may be able to do it, depending on availability and sponsorship.

[waldgeist]

@illustreets

If it is a package that looks unmaintained, perhaps try and search for a recent fork and contribute to that one if it is not already updated.

Yep, my idea was to make it easier to find them by maintaining a fork list.

@illustreets

Both Atmosphere and Packosphere could do with an update to either filter or highlight the minimum Meteor version for each package version.

Good approach. But this would only work if the fork would be pushed to these systems, wouldn’t it?

[illustreets]

@waldgeist

Good approach. But this would only work if the fork would be pushed to these systems, wouldn’t it?

You are right. But, lists are cheap, and in my opinion unreliable and quickly out of date. The best we can do is support the people behind Meteor Community Packages, who is the most suitable organisation for this kind of stuff (unless Meteor Software picks up the initiative, that is). I’d imagine they could do with some help at the moment.

[jam]

@illustreets

Both Atmosphere and Packosphere could do with an update to either filter or highlight the minimum Meteor version for each package version

. There was some discussion on this here: Proposal on Meteor 3 packages compatibility showcasing - #10 by grubba

Maybe the way to do it would be to highlight packages if api.versionsFrom equals or includes 3.0. I recently updated a package for 3.0 compatibility but my minimum version remains 2.8 so I don’t think we can rely solely on minimum version since I imagine there will be other packages that will maintain compatibility with 2.x for some time.

@illustreets

lists are cheap, and in my opinion unreliable and quickly out of date

True but maybe it’s a fast way to get started. Crowdsource a Google doc while the real solution makes its way into Atmosphere / Packosphere.