Post

📣 call for feedback! I'm having second thoughts about the naming of the functions in my #webGL library. TL;DR: is it ok to have functions starting with "use" in a vanilla JS library ? explanation in thread 🧵

I like the hook-style naming with "use" because the functions actually behave like hooks (output destructuring, re-render when updated etc), but I wonder if they could be confused with "real" hooks or composables in a react or vue codebase. I'm not sure if it would be a big issue though.

Also, I don't know what other names to use: I can't remove the "use" because the functions would have the name of the object they return. e.g, "const compositor = compositor(...)" is not possible. And I don't want to prefix "createXXX" on all functions. So yeah, I would appreciate some feedback!

0 reposts0 likes

Most functions create and/or initialize something so it would rather be createXXX, but I don’t really like that 🤔

Julien Sulpis@jsulpis.dev

Ok I understand, in my case I think it would be something like « createRenderPass(…) », but it seems a bit verbose to me. I also thought about a « gl » prefix, like glRenderPass(). It’s shorter and allow to separate WebGL related stuff from JS utils. I think I like this one. What do you think ?

I use vanilla JS signals a lot, and I think they behave much like your hooks. I use them like this: “thing = Thing.get()”. When I write something that’s not a signal it’s usually like “thing = getThing()”. Feels quite consistent and nice.

Ok I understand, in my case I think it would be something like « createRenderPass(…) », but it seems a bit verbose to me. I also thought about a « gl » prefix, like glRenderPass(). It’s shorter and allow to separate WebGL related stuff from JS utils. I think I like this one. What do you think ?

Maybe! Might be annoying in the future if you want to write similar functions for WebGPU or something else and need to come up with a replacement for the “gl” prefix? I guess there are not many neutral options that are short. use, get, do….

Good point, writing similar functions in webGPU has crossed my mind. But since they are low level and the webGPU API is quite different, I don’t think the same functions will work for both. So either it will be another lib, or I use 2 prefixes (glCanvas / gpuCanvas), which seems consistent