How to structure / design events and tasks in a quest system to make code manageable?

I'm creating a Javascript game that provides quests for the user to play through. Each quest has a number of tasks which are completed when certain requirements are met. Below is the design I originally intended to go with.

As you can see, each Task and GameEvent (simplified to Event) has a type and some data (a list of vars). When an event is sent to QuestManager, it is passed along to the active Quest objects who in turn pass it on to each Task assuming their types are the same. Each requirement in the task is then tested against the correlating data in the event. The reason why I don't do 1:1 checks is because an event may have additional data.

e.g data{item: someItem, locationFound: someLocation} != requirement{item: someItem}

This works great in terms of minimising the number of classes that need to be created. Events and tasks are generic so they can be easily created and tested against without creating a ton of sub-classes.

But this design creates a problem. Because of its generality, it is never certain what requirements should be given to a task without first finding an event of the same type and checking the data being sent to it. As the project expands, this becomes a nightmare to manage.

Instead, I could create sub-classes for both Event and Task that would cover the various types, like this:

Event -> ItemPickupEvent, MoveEvent, etc.
Task -> ItemPickupTask, ItemPickedUpAtLocationTask, MoveTask, etc.

But the data is similar between them and seems highly unnecessary.

My final thought was to create data objects to encapsulate the data being passed by certain event types, as follows:

ItemPickupData, MoveData, TalkData etc.

Events and tasks could just be given the appropriate data object. This provides better structure to the data being used. If a piece of data should not be made into a requirement, it could simply be defaulted to null.

In terms of maintainability and structural design, is this an adequate solution or is there a better way to approach this problem?

Thanks.