Hacker News Reader

Comment by jka | Hacker News Reader

Great application and writeup, thanks for sharing (and making it open source)!

The file-based approach to defining data is a good way to go I reckon - it's simple and easy to update (especially with source control). You can always upgrade to something more sophisticated in future.

How complete/challenging does the unit conversion component feel, out of interest? (I'm reading through `conversion.ts` in the codebase at the moment)

By chance I'm working on some ingredient unit conversion code too - I'd be happy to learn from & share experiences. FWIW the tools I'm exploring are Pint[0] and convert-units[1].

[0] - https://github.com/hgrecco/pint

[1] - https://github.com/ben-ng/convert-units

View on HN

Thank you so much for your kind words! As a frequent reader but rare poster, I find HN more daunting than I probably ought to.

Those unit conversion libraries look awesome! Way better than my pile of hacks. I only added the units I happened to use in recipes (surprisingly few). The most hacky thing is probably all the cooking-specific ways of saying "thing" (clove, pack, fillet, sprig, scoop, etc.).

The most interesting problem I ran into with unit conversions was actually around the user experience: when did I want units converted at all? Right now, the app simply always does it before rendering anything. This means converting to the smallest unit of that type, and then picking the largest reasonable unit to display. This can lead to annoying instances where you put an ingredient in one unit, but another is displayed. I also went a little overboard on the fractions, so you see things like "2/5 tsp" which is just absurd.

Glad you did post :)

This is going to be a brief ramble because it's late here in the UK, but I'm keen to respond because those are exactly what I'm looking into too.

Re: finding the appropriate display units, `convert-units` in particular has a method `toBest` which attempts to find the best-matching display unit for a quantity. The main problem is that it's unaware of culinary measurements (i.e. tsp as you mention, which could round up to tbsp, etc) at the moment.

I reckon that with a few additions to that project, and a few judicious extra test cases[0] to assert the right behaviour, it'd be possible to get it to perform smart display rounding on culinary measurements too.

Ideally those units would only be rendered by when a 'culinary unit system' is optionally enabled. That'd avoid any backwards-compatibility issues for the library -- and also because most users just want to see milliliters and liters by default I'd imagine.

As a slight aside, `pint` has nice support for alternative unit systems[1]. I'm planning to use `cgs` for storage of ingredient quantities since it's fine-grained.

Anyway - I'm probably thinking faster than a practical design, but if you have any interest, I'm probably going to look into extending `convert-units` for this use case a bit more. If it's possible to create a common library we could both use to ease some of the display work, I'd be really happy to collaborate.

[0] - https://github.com/ben-ng/convert-units/blob/93883046e43b5b0...

[1] - https://pint.readthedocs.io/en/0.9/systems.html

Reply on news.ycombinator.com