dataValues Technique for PubSub -- It Works but Is it Best Practice?

[vikr00001]

I have a lot of subscriptions that are working well.

Sometimes I run into a situation where I want to return data in this shape:

type Appts {
    id: Int
    originatingUserId: String
    apptWithUserId: String
    apptDateTime: String
    apptTitle: String
    apptNotes: String
    originatingUser: epUserData
    apptWithUser: epUserData
    [.....]
}

…where epUserData is an object.

I find that a query or mutation returns the expected data to my Apollo client on the server.

But with subscription data, there’s a special consideration.

Let’s say I have this code in my createAppointment resolver:

	APPTSubscription.originatingUser = await getUserData(originatingUserId);
	APPTSubscription.apptWithUser = await getUserData(apptWithUserId);

	pubsub.publish(APPT_ADDED_CHANNEL, {
		APPTSubscription
	});

It looks okay at the point of calling pubsub.publish – note that the fields originatingUser and apptWithUser are present:

…but when we get to the subscription resolver:

	APPTSubscription: {
		subscribe: withFilter(
			() => {
				console.log(`subscribed to APPTSubscription by ${Meteor.userId()}`);
				return pubsub.asyncIterator(APPT_ADDED_CHANNEL)
			},
			(objectToPublish, args, context) => {
				let result = false;
				if (typeof (objectToPublish) === 'undefined')
					return result;

…those fields are missing:

Those fields are just gone.

The solution I found was to manually add the fields to dataValues, before calling pubsub:

	APPTSubscription.dataValues.originatingUser = await getUserData(originatingUserId);
	APPTSubscription.dataValues.apptWithUser = await getUserData(apptWithUserId);

	pubsub.publish(APPT_ADDED_CHANNEL, {
		APPTSubscription
	});

Then they do show up as expected in the subscription resolver:

Okay, so I solved it. But did I solve it according to best practices? In other words, is this considered a correct way to do it?