Stéphane Comments

Stéphane

•Created by Stéphane on 7/24/2024 in #help

Weird behaviour with deno autocomplete

Deno is well sourced from the cargo path, it is available from the command line, it just acts weird when I try to autocomplete the rest of the command, and it does not do that with other binaries :/

3 replies

DDeno

•Created by Stéphane on 7/24/2024 in #help

Fresh - Error while running deno run on the built _fresh directory

ah ok, didn't get it like that, thanks for clarifying 🙂 I played with Astro SSG before and forgot that it's completely different 😅 Marking the topic as solved, thanks 🙂

6 replies

DDeno

•Created by Stéphane on 7/24/2024 in #help

Fresh - Error while running deno run on the built _fresh directory

ah ok, so it can be run locally ? Or is meant for deno deploy only ? It was not clear to me what I can do with the compiled assets :/

6 replies

DDeno

•Created by Stéphane on 12/10/2023 in #help

How to use a class name as a qualifier for an enum ?

Thanks again, moving the thread to solved 🙂

4 replies

DDeno

•Created by Stéphane on 12/10/2023 in #help

How to use a class name as a qualifier for an enum ?

Thanks a lot for your answer. That's the conclusion I got by looking through diverse stackoverflow threads, but it's good to see I didn't overlook something. And yeah I tried to get something closer to C++ where an enum can be nested in a class so I could have just one export embedding all the class features. The import * as trick is ok I guess. And yeah I didn't even think about looking at the std lib haha

4 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

this kind of project gives hope about it, cause so far it looks like UI is the complicated part when using Rust

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Thanks ! Looks pretty interesting indeed, I'll give it a go this weekend 🙂

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

And now I want to use Deno to do something similar but it doesn't have a midi module, so I decided to make it 😄

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

I used the npm version a few years ago for a digital arts project where many people could connect to my computer via their phone to control music in a live context, all at the same time, using websockets. It was pretty fun

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Thanks 🙂 it's not really an app, it's meant to be used server side. It's a port of this npm package : https://github.com/justinlatimer/node-midi The idea behind it (for my use case at least) is to create remote midi controllers for basically anything 🙂

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Yeah, I agree with on 🙂 I went with emit for fire haha, matters of taste I guess 😄

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

I didn't know this kind of syntax was possible :

      when<EventName extends keyof T>(
         eventName: EventName,
         id: string,
         handler: EventHandler<T[EventName]>

      when<EventName extends keyof T>(
         eventName: EventName,
         id: string,
         handler: EventHandler<T[EventName]>

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Oh, that looks great, very close to what I'm trying to achieve, I'll give it a try 🙂 Thanks a lot

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Hi again 🙂 Thanks again for the help @ndh3193 I implemented something very similar to what you shared (you can check here : https://github.com/stfufane/deno-midi/blob/main/lib/events.ts for the types and https://github.com/stfufane/deno-midi/blob/main/lib/midi.ts#L258 for on/off/emit) Now I tried some things to take it a bit further, but with no success, and wonder if you'd have any extra knowledge on how to achieve this (maybe it's juste not possible...) Basically, with this API, the user can do this :

midi_in.on("message", ({ message, deltaTime }) => {
  console.log("message callback at ", deltaTime);
  if (message instanceof midi.NoteOn) {
    console.log(message.data.note, message.data.velocity);
  }
});

midi_in.on("message", ({ message, deltaTime }) => {
  console.log("message callback at ", deltaTime);
  if (message instanceof midi.NoteOn) {
    console.log(message.data.note, message.data.velocity);
  }
});

which is nice, but I'd like a way to automatically infer the type of the message variable in the callback, and using generics I just did not find how to do that. My idea is something like this :

export interface MessageEventData<T extends Message<MessageData>> {
  message: T;
  deltaTime?: number;
}

export type MessageHandler<T extends Message<MessageData>> = (
  data: MessageEventData<T>,
) => void;

on<T extends Message<MessageData>>(
  handler: MessageHandler<T>,
): void {
  this.handlers.set(T, handler); // <-- HERE, how to link the type of the generic with the map ?_?
}

private emit<T extends Message<MessageData>>(
  data: MessageEventData<T>,
): void {
  const handler = this.handlers.get(T); // <-- HERE, use the same trick
  if (handler) {
    handler(data);
  }
}

export interface MessageEventData<T extends Message<MessageData>> {
  message: T;
  deltaTime?: number;
}

export type MessageHandler<T extends Message<MessageData>> = (
  data: MessageEventData<T>,
) => void;

on<T extends Message<MessageData>>(
  handler: MessageHandler<T>,
): void {
  this.handlers.set(T, handler); // <-- HERE, how to link the type of the generic with the map ?_?
}

private emit<T extends Message<MessageData>>(
  data: MessageEventData<T>,
): void {
  const handler = this.handlers.get(T); // <-- HERE, use the same trick
  if (handler) {
    handler(data);
  }
}

So that the user would be able to do :

midi_in.on<midi.NoteOn>(({ message, deltaTime }) => {
  // The message is automatically detected as NoteOn yay
});

midi_in.on<midi.NoteOn>(({ message, deltaTime }) => {
  // The message is automatically detected as NoteOn yay
});

I think it'd make a clearer usage with autocompletion and everything running smoothly. But T is a type, not a value, typeof T and T.prototype.constructor don't seem to work either...

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Reading in more details now, and this actually makes more sense to use something like you did in my use case, that's nice 🙂 I'll try to implement this tomorrow, thanks for sharing!

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Looks cool, thank you for the suggestion 🙂 I managed to understand the right syntax for my above issues, but I'll try to go further

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

And btw the linter is not happy but the code runs anyway, I receive the events and can print them without a problem

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Cool suggestion. I'm doing that and now encounter a weird issue. I created this interface (+ the alternative for raw messages)

export interface MidiMessageEvent extends CustomEvent {
  detail: {
    message: Message<MessageData>;
    deltaTime: number;
  };
}

export interface MidiMessageEvent extends CustomEvent {
  detail: {
    message: Message<MessageData>;
    deltaTime: number;
  };
}

and used it like this :

  dispatchEvent(
    new CustomEvent<MidiMessageEvent>("midi.message", {
      detail: { message: decodeMessage(msg_data), deltaTime: deltaTime },
    }),
  );

  dispatchEvent(
    new CustomEvent<MidiMessageEvent>("midi.message", {
      detail: { message: decodeMessage(msg_data), deltaTime: deltaTime },
    }),
  );

But the linter is not happy about it :

Type '{ message: Message<MessageData>; deltaTime: number; }' is not assignable to type 'MidiMessageEvent'. Object literal may only specify known properties, and 'message' does not exist in type 'MidiMessageEvent'.deno-ts(2322)

despite having the propriety 🤷‍♂️ If I do this instead, it's ok...

dispatchEvent(
  new CustomEvent("midi.message", {
    detail: { message: decodeMessage(msg_data), deltaTime: deltaTime },
  }) as MidiMessageEvent,
);

dispatchEvent(
  new CustomEvent("midi.message", {
    detail: { message: decodeMessage(msg_data), deltaTime: deltaTime },
  }) as MidiMessageEvent,
);

But I still get an error when trying to add an event listener :

addEventListener("midi.message", (e: CustomEvent<midi.MidiMessageEvent>) => {
  console.log(e.detail);
});

addEventListener("midi.message", (e: CustomEvent<midi.MidiMessageEvent>) => {
  console.log(e.detail);
});

30 replies

DDeno

•Created by Stéphane on 9/19/2023 in #help

API architecture for generic callback

Usage would look like this, with the user having the choice between the callbacks

midi_in.onMessage({
  rawCallback: ({ message }) => {
    console.log("Raw callback");
    console.log(message);
  },
  callback: ({ message }) => {
    console.log("Typed callback");
    console.log(midi.MessageType[message.type]);
    console.log(message.data);
  },
});

midi_in.onMessage({
  rawCallback: ({ message }) => {
    console.log("Raw callback");
    console.log(message);
  },
  callback: ({ message }) => {
    console.log("Typed callback");
    console.log(midi.MessageType[message.type]);
    console.log(message.data);
  },
});

30 replies

DDeno

•Created by pronoob on 8/29/2023 in #help

What is the difference between JS Map and JS Object?

There's a good explanation on the MDN doc here : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#objects_vs._maps but basically the Map offers a more secure API to manipulate your data than the object does

4 replies