Proposal to reconsider the naming convention

[LcsGa]

I have carefully read the "Why no prefixes" section in the documentation. While I understand the rationale behind omitting prefixes, I am encountering practical issues when using Signality to create my own composables.

The goal of these utilities is often to use them within custom composables. In these contexts, we aren't always working within a class; sometimes we are inside standalone functions, methods, or constructors. This makes the lack of a prefix problematic, as it frequently leads to naming collisions.

For example, in my current project, I have a custom useWorkflow() composable where I need to use title(). Because there is no prefix, I cannot simply assign it to a variable like const title = title(). I am forced to find a workaround name, which feels inconsistent, especially when compared to using these utilities as class properties, where this issue doesn't arise.

I believe this warrants a reconsideration of the naming convention, especially since createInjectable will encourage defining injectables as functions rather than classes.

Personally, I would advocate for a useXxx naming convention. I believe injectXxx should be reserved for utilities that exclusively use inject() under the hood. Since many composables might use inject() alongside other logic (or might not use it at all) useXxx would be a more accurate and flexible standard for the Signality ecosystem.

[vs-borodin]

Thanks for pointing this out. I think we really need to come up with some kind of naming strategy so that users don’t run into issues when creating custom factories.

Perhaps we could organize a vote during the process, encouraging project users to share their opinions or at least cast a vote for one prefix or another.

[LcsGa]

I'm glad we’re on the same page on this! 😄

Regarding the community vote, it’s a great idea in principle, but I’m just a little worried about the timing. Since the project is still quite new and finding its feet, I’m afraid a vote might not give us a truly representative picture of the future user base 😕.

If I were to share my personal take on the naming, I’d favor use* for a few reasons:

• use* vs. inject*: In the Angular world, inject has such a specific technical meaning tied to the inject() function. A composable might be purely logic-driven without actually injecting anything at all. In those cases, use* feels much more flexible and conceptually "right."
• I know some might push back because use* feels "too much like React or Vue," but I honestly think we should focus on what works best rather than worrying about framework labels. Composition is a very mature pattern elsewhere, and I’d love to see us adopt those proven conventions instead of trying to reinvent the wheel just to stay "on-brand".
• I also suspect that people might suggest with*, but to me, that prefix feels like it's meant for extending something (like Angular’s provideRouter(..., withComponentInputBinding())). I personally think it doesn't quite capture the vibe of a standalone factory starting from scratch.

I really feel like leaning into a pattern that’s already been refined in other communities could give the lib a great head start.

What do you think? Do you still feel a vote is the best way to move forward, or would you prefer to just set a strong, opinionated direction?