feat.activities: dto mapping to endpoint

[aberonni]

AB#30664

Checklist before requesting a review

• I have performed a self-review of my code
• I have added tests wherever relevant
• I have made sure that all automated checks pass before requesting a review
• I do not need any deviation from our PR guidelines

[diderikvw]

Now this is easy to read code! :)

[aberonni]

@diderikvw I've tried to align with the guidelines to have one export per file, but I think this is a great example of why I didn't like this guideline to begin with (as per our old discussions about it).

I think that what I've pushed

makes it simpler to answer the question "where should I put this?" but IMHO it does not make the code simpler / easier-to-use / easier-to-read / easier-to-navigate than what was there before:

Not to mention that it is twice the amount of code:

[diderikvw]

Ok, great you addressed these.
Just a few small things left.

One of which here (because I cannot reply there for some reason):

I've tried to align with the guidelines to have one export per file, but I think this is a great example of why I didn't like this guideline to begin with (as per our old discussions about it).

I am happy to have a conversation about changing this convention. But I do want to have some convention on this and not let it depend on "whatever the developer favors who happens to work on this code". IMO having it "all the same way" does improve readability, even if TS code-wise it is not as efficient as could be.

[diderikvw]

What is the necessity of having the fields to be | null? Not having this would make using the interface simpler.

[aberonni]

This stems from the input data being nullable:

121-platform/services/121-service/src/events/dto/get-event.dto.ts

Line 7 in c431e19

[key: string]: string | null;

[diderikvw]

Ok, I would like to discuss this with @PeterSmallenbroek , related to the ##TODOs already in the code.