should there be a stringifier and what should it return?
Closed this issue · 5 comments
Should there be a stringifier for URLPattern? If so, what should it return?
There is no single string input to URLPattern that works for all patterns, so we can't use that as the toString() output.
We could add a general human readable string, but its unclear if that is necessary if devtools already supports iterating properties. With per-component pattern properties its already quite debuggable:
I guess if we add per-component regex getters as well this devtools view will get a bit busier. Having a minimal view of the pattern might be useful. But I will probably wait to see what developers say here.
To clarify, @domenic suggested not providing a stringifier since its likely developers will try to use it as a serialization mechanism and we can't safely produce a single string that can be deserialized with the constructor. We could provide a toJSON() method if folks need that, though.
Now that there is a constructor that takes a single string as an argument, should we revisit whether to provide a stringifier? @domenic, what do you think?
Yeah if you can guarantee that new URLPattern(urlPattern.toString()) behaves the same as urlPattern then a stringifier makes a lot of sense. That's not a trivial property, but it seems doable...
After thinking about this some more I think there are URLPattern objects that can be created with URLPatternInit dictionaries that we still cannot parse from a constructor string. Therefore I think leaving this without a stringifier for now is the right decision.
This is captured by the spec, so closing this.