Optimizing Directus Components: Merging and Prop Improvements

[Fritsch-Tech]

Discussion/Idea

Merging DirectusAsset and DirectusImage Component: Is there a reason why those are separate?

Directus doesn't explicitly distinguish between them (Reference: Directus Documentation). Considering this, would it be beneficial to merge the DirectusAsset and DirectusImage components into a single component? This could potentially simplify the codebase and improve maintainability.

Change DirectusImage props: Simplifying Transformations

Instead of having multiple separate props for each transformation, why not create a single Directus Transformation Prop that accepts either a Preset or a Custom Transformation (of type string | CustomTransformations)? For backward compatibility, we could retain the existing props in the current npm package. This approach would streamline the documentation, programming, and make the reuse of custom transformations easier. Additionally, it would simplify the implementation of default custom transformers.

Add Enums: Improving Type Safety

Currently, we use unions for everything, but with the above changes, we could introduce enums for better type safety and keep backwards compability. This would help maintain backward compatibility while enhancing the codebase with more robust typing.

By implementing these improvements, we can enhance the component's overall usability and codebase structure. Let's discuss and gather feedback to make informed decisions on these enhancements.

Feel free to share your thoughts and ideas regarding these proposed changes!

Thank you for engaging in this discussion!

[gremo]

Merging DirectusAsset and DirectusImage Component: Is there a reason why those are separate?

When I created this library, I was thinking about providing a default renderer (standard img type), maybe this is the reason 😄 Do you think this could be a valid motivation and/or a good idea for DX?

Change DirectusImage props: Simplifying Transformations

Can you provide a real usage example?

Add Enums: Improving Type Safety

What about the debate union vs enum then? 🥲

[Fritsch-Tech]

I don't know. I was thinkink about providing things like that too. But they should probably be in a seperate npm package. That way we can provide them for react and react-native seperatly. Also the current seperation of asset and image limits the overall usability. If i want to make a image downloadable but transform it first, I can't to that currently.
For backwards compability we still could export the Directus Image component but mark it as @deprecated.

Yes, for one it would clean up the types we use a lot. Also it would allow you to define a enum of CustomTransformations and use them as a clientside version of the Transform Preset. Currently one would have to unpack such a object every time.

Yea, i haven't realy read into them before your comment. But after having lerned about both of them a bit more, I would say I think I prefere emuns for usecases with strings like we have. Specificly:

• AuthState
• fit
• format
• Typed PresetKeys via generics (If we add this feature). But I would still give the user the option to use a Union fot this if he likes.