Replies: 4 comments 2 replies
-
This is a great proposal! Some general comments & ideas:
Should we use the name Stencils? Maybe something less specific on the file like
Not sure how this alternative would work since you'd have to define how to locate the templates, which is a positive for the original proposal since plugins already do this for us & allow them to be hosted remotely.
We'll have to be careful here since plugins could have conflicting templates as well. I believe a sane approach to this would be to just pick the last defined template for a specific extension & throw a big warning to the user so they know something may be causing issues.
I'd say that it should disable them all even the plugins, yes. This seems to make the most sense unless we want to rename this to Thanks again for the proposal and the great idea! Do you think this is something you'd be interested in contributing to the project? I'm not too familiar with the part of the codebase but can be of general help for getting around the project. Either way this seems like something Tuist and users of it would benefit from and the use of plugins makes this completely optional! |
Beta Was this translation helpful? Give feedback.
-
Some relevant discussion is also happening around synthesized resources in: #2564 |
Beta Was this translation helpful? Give feedback.
-
This is a great proposal @fila95! Apart from @luispadron, there's not much for me to add. One thing to note is that we should make sure that custom strings, fonts, images and plists templates will replace the templates defined in tuist which is something to be mindful about during the implementation. |
Beta Was this translation helpful? Give feedback.
-
I have some additional ideas for this, so I'll try to take this on. |
Beta Was this translation helpful? Give feedback.
-
Need
Handling resources is quite a common operation during iOS Development.
Being able to access them in a type-safe and module-safe way is something really important when it comes to develop modular apps.
Tuist already comes with some built-in core resource accessor generators but they are limited to just some file types and don't allow for further customisation.
What I'd like to propose here is a solution that aims to allow developers specify how and which resources can be safely accessed, providing a custom way to synthesise their accessors.
Motivation
Resources are not limited to only images, plist, strings. There might be other types (for example Lottie animation) that could benefit from this proposal.
Also, different teams might want to handle all these kind of generated resources in a different way, and at the moment Tuist provides only a single non-customisable way to do so.
Detailed design
After a brief discussion here, plugins seems to be the right place to build this enhancement.
The plugin structure might be extended like the following example so that it adds the possibility to store custom template stencil files:
The plugin manifest might become something like:
Where
resourceSynthesizerTemplates
is a set ofResourceSynthesizerTemplate
:There could be added more default partial implementations but for the sake of this document let's stick to the main ones.
An example of an implementation of a plugin manifest supporting such configuration might be:
Tuist Engine Edits
To support the suggested changes there are some Tuist internal components that need to change in order to properly extend such plugins:
SynthesizedResourceInterfaceProjectMapper
andSynthesizedResourceInterfacesGenerator
should become aware of the plugins customization and account for them while generating resource interfaces.Alternatives
Another alternative would be to define the same templates configuration at Tuist's
Config.swift
level, removing thedisableSynthesizedResourceAccessors
case and exposing another option that might be like:Adoption strategy
This won't be a breaking change since extenral APIs will change only for plugins, having the additional
resourceSynthesizerTemplates
parameter default to an empty set.How we teach this
If this proposal gets approved, just the documentation should be updated in order to properly explain changes. In particular:
Accessing resources
section and update it referring also to pluginsPlugins
sectionUnresolved questions
stock
sibling?disableSynthesizedResourceAccessors
config do in this case? Does it disable also the plugin ones?Beta Was this translation helpful? Give feedback.
All reactions