Inconsistencies regarding Action, Topic and Service

[ikwilnaarhuisman]

While implementing Actions, Topics and Services I ran into a minor inconvenience; to instantiate each of these types it's rather inconsistent.

You can instantiate a (ROS2) Action without defining TGoal, TFeedback and TResult. Because it defaults to unknown. This is great when you're actively developing and don't know the definition just yet.

ref:

/**
 * A ROS 2 action client.
 */
export default class Action<
  TGoal = unknown,
  TFeedback = unknown,
  TResult = unknown,
> {

This isn't the case for Topic and Service. So for every new instance you create of these two you have to define their related types. When working with Webstorm (Which forces you to fill them in and fair) this is quite annoying.

Ref:

/**
 * Publish and/or subscribe to a topic in ROS.
 *
 * Emits the following events:
 *  * 'warning' - If there are any warning during the Topic creation.
 *  * 'message' - The message data from rosbridge.
 */
export default class Topic<T> extends EventEmitter<{

And:

/**
 * A ROS service client.
 */
export default class Service<TRequest, TResponse> extends EventEmitter {

[MatthijsBurgh]

@EzraBrooks @sea-bass What do you think? Do we want to go for all unknown or all require a type?

[EzraBrooks]

I'm in favor of doing T = unknown by convention in this codebase. I think our original pass adding these types was before I had realized how convenient it was to have type arguments default to unknown for simple use cases where you don't care about actually handling the response (i.e. you send a Service Request and you just care that it was dispatched, not what the Response was).

Given that roslibjs doesn't internally do any type validation, this also would allow people who care strongly about the integrity of their message types to easily create rules in their codebase to ban the use of type arguments to these functions (since they're basically unverified type assertions) and write a wrapper function in their codebase that uses something like Zod to safely validate the unknown data into a real type.

I'd be happy to review a PR that adds = unknown to these type arguments.

[ikwilnaarhuisman]

It shall be done, then. Awesome