SmartText spends one constructor parameter per span type: config, addressConfig, phoneConfig, urlConfig, dateTimeConfig, emailConfig.
Six types, six parameters. The roadmap adds flight, date, hashtag, mention and custom detectors, which would mean eleven or more. That is not a simple API, and every type added makes it worse.
This blocks the type expansion work and should land before any new type.
Proposed shape:
SmartText(
text,
style: baseStyle,
linkConfig: ItemSpanConfig(...), // applies to every link type
spanConfigs: { // per-type override, optional
ItemSpanType.address: ItemSpanConfig(...),
},
)One parameter that scales to any number of types, const-able and declarative.
A builder form (spanConfigBuilder: (span) => ItemSpanConfig(...)) would additionally allow per-span logic, such as styling links to your own domain differently. It cannot be const and most users will not need it. Worth adding only if someone asks.
Migration: ship the map in the next minor release with the six existing parameters marked @Deprecated, and remove them in a later major.
Found during the v0.4.0 codebase audit.
SmartTextspends one constructor parameter per span type:config,addressConfig,phoneConfig,urlConfig,dateTimeConfig,emailConfig.Six types, six parameters. The roadmap adds
flight,date,hashtag,mentionand custom detectors, which would mean eleven or more. That is not a simple API, and every type added makes it worse.This blocks the type expansion work and should land before any new type.
Proposed shape:
One parameter that scales to any number of types, const-able and declarative.
A builder form (
spanConfigBuilder: (span) => ItemSpanConfig(...)) would additionally allow per-span logic, such as styling links to your own domain differently. It cannot be const and most users will not need it. Worth adding only if someone asks.Migration: ship the map in the next minor release with the six existing parameters marked
@Deprecated, and remove them in a later major.Found during the v0.4.0 codebase audit.