Directives improvements

[elite174]

Looks like current implementation of directives is a bit "hacky": a developer needs to add extra stuff to babel-config and deal with global types.

Is it possible to change the current syntax?

Now it looks like this:

<input use:someDirective={[args]} />

Instead it could be something like this:

<input use={[someDirective, args]} />
In this case it's possible to add extra field to the CustomAttributes<T> interface.

So this implementation implies that JSX elements can have multiple use attributes. In this case no changes to babel-config needed.

WDYT?

[atk]

Then we could just allow multiple ref props and be done with it. Unfortunately, multiple definitions of the same property is supposed to overwrite previous assignments according to the JSX spec.

Also, we have similar mechanisms for on:/oncapture:/attr:/prop:, so it makes sense to apply it to directives, too.

The only improvement that I would like is to directly expose the interfaces in order to ease their extension.

[elite174]

True with refs.

I think that the current approach is not so "solid" as it may be, because it enforces a developer to do extra stuff. Especially, babel stuff. This thing seems to be unfinished.

Another idea is to have single attribute use and pass the data via closures:

type Directive = (el: Element) => void;

interface CustomAttributes<T> {
   ...
   use?: Directive[] | Directive;
}

Then we can write like this:

const C = () => {
   const directive: Directive = (el) => {/* Do some stuff with el, getting the data from the closure */}
   return <div use={[directive]}>Hi</div>;
}

[atk]

What "babel stuff" do you have to do? Except using babel-preset-solid (which you'll need for the JSX transpilation anyways), there's nothing you need to do to use directives.

All you need to do is to make typescript accept your directive, if you are using typescript; if not, it should work out of the box.

That leaves the question, shouldn't we be able to use any directives/event handlers with the required function signature in order not to have to extend the types. That's a discussion worth our time.

[elite174]

You're right, I needed to describe the issue with babel and directives.

At the moment directives processed with TS in a way that TS assumes the directive function is not used. This may lead to directive code elimination and TS eslint errors like "unused code". To deal with it we need to hack the things:

1. Add export keyword to the directive function to get rid of "unused code" error.
2. Do smth like this Selective babel compilation using directives #286

[atk]

Since directives are about code reuse, not exporting a directive is probably not considered a strong use-case. The same applies to the aforementioned events.

However, there might be a solution that allows type safety for libraries as well as convenience for less restrictive use cases.

[samuelstroschein]

I got multiple directives working with one ref prop. See #805 (reply in thread)

[izznat]

Another solution is to change the proposed syntax:

<input use={[someDirective, args]} />

To accept multiple directives:

<input use={[[directiveOne, args], [directiveTwo, args]]} />

// or array of object syntax
<input use={[{ 
        directive: directiveOne, 
        args: [arg1, arg2] 
    }, { 
        directive: directiveTwo, 
        args: [arg1, arg2] 
    }]} 
/>

Benefits:

1. Typescript users don't need to patch the JSX type. It also prevent global type pollution.
2. Infer args type with generic.
3. No need to set onlyRemoveTypeImports: true option for vite-plugin-solid to prevent directive removal that is not local (coming from another file or npm package)

Drawbacks:

1. The new syntax is not as simple as the current one.

[atk]

I think the required type definitions are mostly a non-issues, since the main point of directives is reusability, a pattern most likely employed by libraries, so it makes sense to keep the definitions of types and functions in the same file.

The problem that typescript's over-eager tree shaking eats the import is one that should be fixed, though. However, I'm a firm believer in fixing bugs where they arise, so we should try to help fix typescript instead of making Solid worse in order to work around it.

[samuelstroschein]

Required type definitions for directives do not seem like a non-issue to me.

The required type definitions are one more step to get directives working with TypeScript. Raises the learning curve and leads to frustration among beginners.

[samuelstroschein]

The title of this discussion should be changed to fix directives in typescript and merged with

• Imported directive not defined (with TypeScript) #1005
• Directive function is not defined #569
• TypeScript: Undefined directives when imported #845

Directives in typescript are defacto not working, the workarounds lead to other bugs, and discussions and reports are all over this repository. Let's aggregate the all discussion in this discussion.

[samuelstroschein]

How about the following syntax?

Directives expose the element ref and iterate over an array of functions that take the element ref as the first argument. Anonymous functions can be used to pass additional arguments.

// single directive
<div directives={[clickOutside]}></div>

// single directive with arguments
<div directives={(element) => [clickOutside(element, args)]}</div>

// multiple directives
<div directives={[clickOutside, someOtherDirective]}>

Pros

• works with typescript
• no required type declarations, see this comment
• (if directives are used as a keyword, no breaking changes. use can be marked as deprecated for solid 2.0`

Cons

• ???

[samuelstroschein]

Follow up:

Works out of the box with Solid refs

<div ref={(element) => [clickOutside(element, () => setIsFocused(false))]}></div>

[snnsnn]

Directives are syntactic sugar over ref but here in this thread they are used like props. How are we going to differentiate is not addressed. The idea with directives is they are like decorators, you don't need to change your component to use them. Yes, they are applied to elements but component logic remains same.

[xdev1]

tl;dr: Just read the last few lines of this comment 😉

---

I've not seriously worked with solid, yet. Just a bit noodling around with Solid Playground. So please let me share a kinda Solid beginner experience when meeting Solid directives for the first time.

I start reading the Solid tutorial. The first issue I meet is the follwowing:

Okay, I think: The IDE is just not smart enough for Solid.

Then I try to modify this directives example a bit on Solid playground, using TypeScript. Well, I meet the next issue:

Okay, as a TypeScript user, I know that you may have to extend an interface somewhere (I guess, that was meant in the following sentence somewhere above: All you need to do is to make typescript accept your directive [...]).
I guess, it's described somewhere on the Solid website what exactly has to be done here. Frankly I've not read everything there. So, I do not know what to do here. But a quick search on Github and I meet this line here:

solid/packages/solid/h/jsx-runtime/src/jsx.d.ts

Line 65 in 89baf12

interface Directives {}

Looks promising ... another search on Github leads to the following lines:

solid/packages/solid/web/test/element.spec.tsx

Lines 8 to 14 in a209b35

	declare module "solid-js/jsx-runtime" {
	namespace JSX {
	interface Directives {
	getRef: boolean;
	}
	}
	}

... looks even more promising, now.

Okay, I give it a try:

declare module "solid-js/jsx-runtime" {
  namespace JSX {
    interface Directives {
      clickOutside: any; // `any` should finally be replaced with the proper type, of course
    }
  }
}

Seems to work ... fine!

To resume, issues and challenges are:

1. That 'clickOutside' is declared but its value is never read warning
2. Extending that Directives interface
3. Asking yourself the question: "Why does Solid pay such a high price for such a little syntactic sugar?!?"

I agree with the following comment somewhere above, in real-world the first two points are not a big issue:
[Edit] Sorry, I was completely wrong with that: Point 1 is of course a big issue in real-world (for example, if ESLint is configured very stringently).

Since directives are about code reuse, not exporting a directive is probably not considered a strong use-case.

I friendly disagree with the following comment

we have similar mechanisms for on:/oncapture:/attr:/prop:, so it makes sense to apply it to directives, too.

use:someDirective uses a variable name, that is completely different to on:/oncapture:/attr:/prop:, isn't it?

What's wrong with @elite174's propsal? Is all that strange use:whatever syntax really better/easier?
#805 (reply in thread)

Btw, I personally would consider to use ref=... instead of use=..., if it is somehow possible to add array support for the ref property:

Then you could use something like

<input ref={someDirective(a, b, c)} />
<input ref={[directiveOne(x), directiveTwo(y, z)]} />

[izznat]

Typescript 5 added --verbatimModuleSyntax option that will leave non type imports as they are. I'm not testing it yet, but it should solve this issue if babel also supports it.

Related Typescript 5 RC release notes.

[oskbor]

I was thinking on how tanstack/router solved a related (?) problem with typesafe links, with the elegant solution that you import <Link> from the router instance rather than from the library.

Maybe something like this could work for registering directives for your app?

// app.ts
import {extendBaseElements}  from "solid/something"
const app = extendBaseElements({
  directiveA: () => ..., 
  directiveB: () => ....
})

export default app

// button.tsx
import {button}from './app.ts'
const myButton = () => <button use:directiveA={} use:directiveB={} />

If the lowercase jsx elements cant be changed, it could return uppercase Button instead of button (but I guess that can be done in userland already)

[subframe7536]

I write a plugin that auto inject directives at compile time, which maybe useful

https://github.com/subframe7536/unplugin-solid-directive

but I quite agree that <input use={[someDirective, args]} /> is a better solution

[salmankhalid-plt]

#805 (comment)

I started working with solid last week, and had a great time using it, till the time i ran into the exact same issue and i landed on this thread. Yes honestly the use: and on: might look great and feel easier ... but it is too much magic i think .. also it is such an off set with rest of soildjs work flow... out of a sudden : based syntax ... i think this is an excellent proposal and it is not only for TS to be honest .. after all the <tag attr1="" onclick="" > is standard html syntax but <tag use:function = .. >

once again Love the library using it for a week and i kept on thinking why i was using react all this time

[Blankeos]

Adding to this discussion... I agree it feels a bit hacky. I have this autofix with VSCode on my codebases and it removes the import because the LSP thinks it's not being used, but SolidJS does.

  "editor.codeActionsOnSave": {
    "source.organizeImports": "always"
  },