[RFC] Refactor away the use of component camelCase identifier types exposing the general props members

[shayanhabibi]

Issue

The constraint of properties by types is great in that it takes advantage of the compiler warnings, and also exposes the appropriate members in intellisense/autocompletion. I have found it frustrating that the autocompletion is polluted by the general properties from feliz.

If there are specific properties/members that have been defined for a component, I want to see those first. They are usually the most significant properties to consider utilising first.

I looked for some method to accomplish this while maintaining/utilising the type safety.

props

This was an implementation I used in Feliz.Shadcn.

Since we can't use the prop keyword (as it collides with Feliz and does not achieve the same outcome that this implementation does), we can use a abbreviated type definition:

type [<Erase>] props<'T> = prop<'T> // still uses the FelizProps.fs prop type

Whenever in a scope that requires a specific components property type such as IButtonProp, you can use props.className and the compiler will infer the type to IButtonProp and not raise any errors or warnings.

There is an issue I don't like about this though, and that's that it is unconstrained. There would be no way to create a property type which doesn't allow normal html properties. There are cases where custom components are implemented in this manner.

To resolve this, the type is constrained with a static member:

type [<Erase>] props<'T when 'T : (static member inline propsInterface : unit)> = prop<'T>

The props type will only be accepted when the property type of the component interfaces with it using the static member definition

type [<Erase>] IButtonProp = interface static member inline propsInterface : unit = () end

When this is not the case, the compiler raises an error.

Pros

This allows the custom properties of an element be accessible within an unpolluted scope. General properties can still be used, and they can also be disallowed.

The erased types mean nothing extra is added to the javascript bundles. All of this constraint is managed by the F# compiler.

Cons

This decreases UX of developers in accessing all properties from one identifier.
For my project, I personally prefer this. I have introduced a lot of components that have custom properties and don't accept general properties. I also am still trying to find a way to constrain properties to specific elements in some non-painful way.

Conclusion

I think the issue of addressing the pollution of property scopes is important, but there could be other ways I am not aware of. It would be nice for intellisense to lower the priority of inherited/interfaced members and rearrange them as such.

In this example, I have the Shadcn calendar which has an extensive property list ~ 40. Viewing them is simple.

I can still access and use the normal properties.

No warnings.

---

This component does not expand extra properties, so it will raise an error if you try give it something that's not defined

The static member that constrains the type can be named as something that'll be useful in the error message.

[sydsutton]

In my Intellisense experience using the library, the native properties for any specific component show up at the very top of the list, and any nested property functions, like X.appearance for example, always shows up at the very bottom of the list. For Fui.spinner, the only spinner-specific props are root, label, spinner, and delay. For the nested functions there's only as', appearance, labelPosition, and size. In this example, size doesn't show up at the bottom because it's both a native prop and a FelizProp, so it's sorted alphabetically. If this isn't the case for you, let me know, but after realizing that, it's helped me sort through all of the properties much faster.

[shayanhabibi]

Is this on VS Code? I might have to give it a shot if that's the case. My intellisense seems to do grouping by type and then alphabetically. So I'll have the modules at the bottom as you do, but the rest are mangled and mixed up :(

But at least this gives me hope I can resolve this without having to grind through things like this hahaha

[sydsutton]

Yes, I use VS Code.