Use TypeScript types for check in methods

copleykj · October 13, 2023, 2:51am

One other thing that I forgot to mention about zod with zodern:relay is that the React-Hook-Form library also has a fantastic zod integration so you can share you schema’s across client and server, get validated and type safe method params, form data, as well as a type aware form integration. If you are passionate about type safety you’ll absolutely love this, and if you’re not yet, you will be after using tools like this for a while.

There is one thing that’s still missing from Meteor’s type safety story though. Currently if you pass a type to your meteor collection it will set up inference for all of the methods on the collection and when you run a find or find one, it will return a document or a cursor of documents with that type you specified. But what if you have a Profile type and it has a firstName, lastName, bio etc. you pass this to the collection via the type parameter and that’s the type of documents. Then you do something quite normal and you specify that you only want the firstName field in the find method options. Now the type for the return lies and tells our tooling that all the fields are available on each document of the result set. For some this might not seem like that big of a deal, but If you’ve ever worked with a data stack like TRPC with Prisma you understand the DX that you are missing out on. This E2E type safety all the way from the database to the client, this for me, is the Holy Grail, and I’m hoping to make this a reality over the next few months by helping to surface a bunch of code written by Evan Broder for his Jolly Rodger project.

lucfranken · October 13, 2023, 5:19am

Do you mean this in the context of subfields? So fields like:

Meteor.user().profile.firstName
Meteor.user().profile.lastName

//or

Meteor.user().profile: {
  firstName: 'John',
  lastName: 'Doe',
}

?

We actually don’t use that as DDP has no reactivity on subfields

github.com/meteor/meteor

Support merging subfields in DDP (or separate multiple subscriptions instead of merging)

opened 09:30AM - 18 Feb 15 UTC

closed 07:15PM - 09 Jun 17 UTC

Siyfion

Type:Feature Project:DDP

**_1 Upvote**_ Rather than recreate the entire thread here, the full details of …the issue can be found here: http://board.meteor-talk.net/t/multiple-subscriptions-for-single-collection/64 I'm starting to think this is a more serious bug than I first thought; however I'm still none the wiser whether it's a core Meteor issue, an Iron Router issue or a 'me' issue!

github.com/meteor/meteor-feature-requests

Support merging subfields in DDP (or separate multiple subscriptions instead of merging)

opened 07:39PM - 09 Jun 17 UTC

jalik

Project:DDP

Migrated from: meteor/meteor#3764 It's not possible to subscribe to a publica…tion multiple times to get different subfields. For example, let say we have a collection where each document have a `data` attribute, inside this `data` attribute there can be anything (temperature, speed, etc), so each document can be different and the use of a data attribute allows to put anything inside without taking the risk to override "meta attributes". So the simple publication below : ```js Meteor.publish("data", objectId, fields, () => { return Data.find({objectId}, {fields, sort: {createdAt: -1}}); }); ``` Would return this kind of data : ```json [ { "objectId": "P0I6JsjAfXepz5", "createdAt": 1497036846026, "data": { "temp": 78.9, "tempUnit": "C" }, { "objectId": "uKl9pR5m73za", "createdAt": 1497036848287, "data": { "humidity": 62.3, "humidityUnit": "%" } ] ``` Now imagine that we have a dashboard with several monitors that should return specific data for different objects, we need to subscribe multiple times to the same subscription with different params : ```js Meteor.subscribe("data", "uKl9pR5m73za", {objectId: 1, createdAt: 1, "data.humidity": 1, "data.humidityUnit": 1}); Meteor.subscribe("data", "P0I6JsjAfXepz5", {objectId: 1, createdAt: 1, "data.temp": 1, "data.tempUnit": 1}); ``` This is a simple example where objects are very small but in real they contains more than 2 values in the `data` attribute, so we only need to get the needed ones, thus filling the `fields` param of the `data` publication to optimize the query. The problem is that it only works for the first subscription, the following subscriptions do not return the other subfields of the document, forcing us to get the full content `data` even if we don't need it...

For example explaines this. Or has this been solved between in case we missed it?

As for this issue we just name fields properly as top-level fields which works out:

Meteor.user().firstName
Meteor.user().lastName

copleykj · October 13, 2023, 1:35pm

No, I’m just talking TypeScript in this case. I’ve always been a staunch advocate of keeping a flat document structure due to this limitation of Meteor’s mergebox, which is why I created socialize:user-profile for the example scenario, but that’s a topic for another time.

To clarify what I mean above take the following code as an example.

import { Mongo } from 'meteor/mongo';
import z from 'zod';

export const ProfileSchema = z.object({
  firstName: z.string(),
  lastName: z.string(),
  birthDate: z.date(),
  bio: z.string(),
});

export type Profile = z.infer<typeof ProfileSchema>;
export const ProfilesCollection = new Mongo.Collection<Profile>('profiles');
export const p1 = ProfilesCollection.findOne({ firstName: 'John' });
export const p2 = ProfilesCollection.findOne({ firstName: 'John' }, { fields: { firstName: 1 } });

No we see here that we have 2 similar queries to find a single document, the difference is that we restrict the second one to the firstName field using { fields: { firstName: 1 }}. This of course means that the return will be an object with the shape { _id: string, firstName: string } or it will be undefined if no document is found. The issue is that if we examine the information typescript knows about this return, we find out that it thinks we have a full profile when a document is found as exampled by this screenshot using 2 slash to surface TypeScript info.

If you notice, it also doesn’t know that there is going to be an _id field on the document as well.This means TypeScript has given us improper information which is a source of totally preventable runtime errors.

If Meteor is ever to be taken as a serious tool for creating large scale codebases, the type safety story is going to have to get a lot better.

tosi · October 18, 2023, 9:01am

Can someone please give me (a related) advice?

It looks like I am unable to use zodern:relay in a Svelte project (and React probably as well).

Does it still work?

Is GitHub - Grubba27/meteor-rpc: Meteor Methods Evolved something I should prefer (it doesn’t look as simple as relay)?

Has anyone made any of these work with Svelte?

copleykj · October 20, 2023, 11:19am

I have this working fine in React. This error looks like the Babel plugin isn’t working properly.

tosi · October 20, 2023, 11:38am

Thanks, I looks like it doesn’t work on Windows :(.

zodern · October 25, 2023, 10:17pm

This is now fixed. The latest version of the babel plugin is able to run on Windows.

tosi · October 26, 2023, 7:36am

Amazing, thank you zodern. There is one more issue I logged as a bug (with a workaround). I can confirm the type checking is working well on Windows now.