Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support to restrict to('best') to input measurement system #216

Closed
mebeingken opened this issue Jun 28, 2021 · 9 comments
Closed

Add support to restrict to('best') to input measurement system #216

mebeingken opened this issue Jun 28, 2021 · 9 comments
Assignees
Labels
enhancement New feature or request

Comments

@mebeingken
Copy link

Thanks for your consideration...

Currently

convert(16, 'tablespoon').to('best')

results in 236.5882365 mL, which is accurate but perhaps not the best option as 16 tablespoons = 1 cup.

It would great if the best option could be restricted to the measurement system of the input.

Or perhaps I have missed how to do that today?

@jonahsnider jonahsnider added the enhancement New feature or request label Jun 28, 2021
@jonahsnider jonahsnider self-assigned this Jun 28, 2021
@jonahsnider
Copy link
Owner

jonahsnider commented Jun 28, 2021

That would be a good feature to add. The reason this doesn't happen currently is because internally tablespoons and milliliters are treated as the same unit family (volume).

Would changing the function like this be good?

// Automatic
convert(16, 'tablespoon').to('best'); // 1 cup
convert(0.5, 'liters').to('best'); // 500 mL

// Choose
convert(16, 'tablespoon').to('best', 'metric'); // 236 mL
convert(16, 'tablespoon').to('best', 'imperial'); // 1 cup

@mebeingken
Copy link
Author

That implementation looks great to me!

@mebeingken
Copy link
Author

@jonahsnider thanks for considering this new feature...for my planning, would this be something coming soon, or more like weeks away?

@jonahsnider
Copy link
Owner

I can probably release a working version of this in the next few days. The reason it's taken this long is because of difficulties I had in (premature) optimizations for bundle size & speed.

@jonahsnider
Copy link
Owner

Unfortunately I still haven't had a chance to make much progress on this feature, I'm not sure when I'll be able to get it in a usable state ready for release. If it's very important for you to have this functionality I'd suggest switching to a different library until I can get this finished (and I will get it finished eventually, I promise!).

@mebeingken
Copy link
Author

Thanks for the update Jonah. I'm waiting for yours for now. I haven't found the right combination in other libraries that handles the "best" uom, and is available as UMD...which is likely more due to my skills than availability. 😄

@jonahsnider
Copy link
Owner

Finally got to finishing this and it's been released in v4.1.0 (the CI/CD bot should have announced that here but it got ratelimited).
The only limitation is that the input measurement system can't be inferred, instead it will default to metric. See the readme for usage examples.

@dRoskar
Copy link

dRoskar commented Sep 10, 2024

Hello, is there a way to differentiate between US imperial and UK imperial here?

@jonahsnider
Copy link
Owner

Hello, is there a way to differentiate between US imperial and UK imperial here?

Please use #676 or create a new issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants