Comments (10)
I encountered an interesting API design dilemma that I'd like to get a recommendation for.
Please could you clarify the API design dilemma? "An option that is resolved at core operation calltime, rather than construction time" opposed to "making the core operation (usually format
) as lightweight as possible"?
Resolving the unit
component at runtime should be sufficiently lightweight for runtime, right? [1] Did you find any trouble in particular please?
1: Resolving the unit
component at runtime involves asserting the passed value, deducing entry
(as a combination of unit
and style
) and internally picking an initialized-relativeTimeFormatter-at-construction-time from a hash/dictionary given entry
, right? Noting that FormatNumber and ResolvePlural both have to happen anyway regardless of this unit
resolution to happen at runtime.
from proposal-intl-relative-time.
Please could you clarify the API design dilemma?
The dilemma is how to provide user with both, a formatted value, and ability to learn what unit has been selected in the bestFit
scenario, when the API only anticipates the resolution
to happen at the constructor time and provides resolvedOptions
to expose the resolved values.
The resolvedOptions
do not apply when the resolution happens at format
time.
We either have to return both, the formatted value and the unit, or provide two APIs - one for retrieving a formatted value and one for retrieving the unit bestFit
resolves to.
I presented those two as examples.
There may be other solutions that I didn't think of.
from proposal-intl-relative-time.
The reason I'm bringing it up is because I believe that we should understand how we'll want to approach this in 2.0 API (when/if we add bestFit
) to make the 1.0 forward-compatible.
from proposal-intl-relative-time.
Thank you for the clarification @zbraniecki. I understand you're raising one additional challenge on top of the ones raised so far [1] for bestFit
which basically is how the user should identify which unit was chosen by the bestFit resolution.
The reservation I have about your proposal (a) (the one that returns an object) is that the return type becomes different for the same function only because of a different option. What makes proposal (b) more appealing to me.
Alternatively, could we use parts to identify the unit? This is, could we use type
returned by formatToParts
to identify the unit? It seems like we're indeed using the unit
when the output is numeric 1.1.3 5.f. We would have to "fix" it for the literal
case...
1: In README.md, "... to implement a bestFit algorithm, which has its own API challenges with respect to standardizing an approach that works for all cases. See #7, #14, and #15. We'd probably need to provide a flag for users to fill, with no default setting, to choose between options for calendar calculation."
from proposal-intl-relative-time.
I much prefer your second option, rtf.resolveBestFitUnit(5)
. Most users most of the time will just spit the result out and having to dereference the value just seems like an extra step. Also, if I understand correctly, your first option only returns an object if the unit
argument is "bestFit" and a string otherwise. I generally find APIs where the value of the arguments control the return type to be frustrating. For example, if my code decides "bestFit" is the unit to use (as opposed to having it hardcoded), I also have to branch the code that interprets the result.
A possible alternative is for formatToParts
to provide not just a value
for the unit but also a normalized unit
, like
[ ...
{ type: "unit", value: "sec", unit: "seconds"}
...
]
Where the unit
is always the full string (second vs sec) and always in English. That requires a little more work on the user's part, though. Edit: I somehow missed that @rxaviers had this idea too.
As a separate matter, I'm not 100% sure I understand the example. Is it the case that when specifying "bestFit", the first argument is always considered to be in seconds? If so, I would have expected milliseconds there, so like:
rtf.format(5, 'bestFit') //=> "less than a second"
rtf.format(5000, 'bestFit') //=> "5 seconds"
rtf.format(5000000000, 'bestFit') //=> "2 years"
But perhaps this has already all been decided; I'm not trying to relitigate anything.
from proposal-intl-relative-time.
Alternatively, could we use parts to identify the unit? This is, could we use type returned by formatToParts to identify the unit? It seems like we're indeed using the unit when the output is numeric 1.1.3 5.f. We would have to "fix" it for the literal case...
I agree with @rxaviers here. formatToParts
is the mechanism that we have invented to offer you more details about the formatted value, and that one can have extension points to provide any sort of detail that you want to offer.
This is also a very edge case, just like the other cases. Imagine that you want to know if the weekday is part of the formatted value when using DateTimeFormat. The fact that it is part of the resolvedOptions doesn't really mean that it will be part of the final output, so they only way you have to know that is by inspecting the parts.
Aside from that, option1 is not really an option because all formatters are suppose to produce a string value rather than object. And option2 is probably ok, but I will argue that formatToParts should be sufficient.
from proposal-intl-relative-time.
Cool. The action item to move on with formatToParts
is to
- "fix" it for the literal case...
from proposal-intl-relative-time.
Well, if you show "yesterday" that doesn't have to be a literal, it could be something else that specifies the unit notation of the text as well. @icambron suggestion seems to be fine, maybe bikeshedding on the value of type
.
from proposal-intl-relative-time.
I like the ftp approach. Wondering if there's a way for us to improve the datetime and number ftp to give more data.
from proposal-intl-relative-time.
This question seems to be answered, so I'm closing this issue. A built-in "bestFit" API could be added in a follow-on proposal, as Intl.RelativeTimeFormat is already at Stage 4.
from proposal-intl-relative-time.
Related Issues (20)
- Docs(MDN) : Intl.RelativeTimeFormat HOT 9
- Update status on README
- Handle cut-off logic / distance with a given Date HOT 5
- Accept BigInt in format/formatToParts HOT 2
- Ambiguous Polyfills section in docs HOT 2
- Add an option to remove the prefix HOT 2
- It would be nice to document the expected placeables in the pattern. HOT 5
- request New API for format relative time from now HOT 5
- Review @@toStringTag value HOT 1
- "an optional argument value" HOT 1
- Remove references to InitializedIntlObject HOT 3
- Create options objects with null proto HOT 1
- Question: why is minimumIntegerDigits set to 2? HOT 6
- Question: What about other NumberFormat options? HOT 2
- resolvedOptions does not need undefined check
- isFinite() does not seem to be formally defined HOT 1
- Review handling of "narrow" style HOT 6
- Incorrect "yesterday" examples HOT 6
- PartitionRelativeTimePattern accepts non-time values HOT 1
- Allow to modify the numbering system through "nu"? HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-intl-relative-time.