cjblomqvist
commented
4 years ago To add som background on the why... The current version is quite limited. The most critical part is the lack of sizes which it works with. This could be remedied using a larger sizing table. Eventually, you'll realize that sizing tables only take you so far. After doing some significant research, one can conclude that:
- ISO is probably the only standardized way of converting that covers all cases (due to its use, or at least strives to use, formulas rather than tables)
- A sizing table that really covers all sizes would be huge.
- It's also probably not really doable, since rounding can cause issues. For example, some sizes will one way map to 2 sizes of another system. When converting back (with sizes with the same problem) this can cause confusion, as the sizing would then round to a different size). This is not possible to map properly in a table.
To support the ISO structure, while still keeping it flexible/customizable, it was better to add the "systems collections" concept, with ISO being the default/standard to use. The benefits of this new "collection of systems" approach is that:
- If one really prefers the table based approach, it's possible to do that by adding systems which use a table underneath. This can be beneficial if one has a specific way of converting sizes (as is quite common unfortunately).
- It supports the ISO system out of the box, and other formula based approaches.
- The core is very lean, while still supporting a lot of features (such as easily and customizable rounding, base system selection, pretty formatting, etc - features that were not there before)
- It's fully tree shakeable.
- The iso system can easily be customized for a leaner build/less code to run, should one desire (by only including desired systems) by creating a new collection of the iso systems one wants to use.
- For formula based approaches, there's no need to have various find-the-closest-suitable-size functions - making it much easier to handle.
- The current ISO system is also very easily customizable, in that features of one system can easily be re-used for other systems (all systems basically depend on the 3 core systems/sizing approaches; mondo, eu and uk). If one wants to modify a system, it can easily be done.
Let me know your thoughts! In case this is all too much and you don't want to dig deeper into footwear sizing conversion (as I apparently have - I work for a company working with footwear sourcing globally with buyers/suppliers on all continents and 50+ countries - hence my interest in this...), let me know and I'll happily help you out in maintaining this for the future (this seems to be the only package I could find in the JS/Node world (and C# world) that deals with conversion - so seems like a worthwhile effort to create a standard here).
alisonmonteiro
Complete rework of the whole package. Adds a new API interface, to support a wider range of scenarios, while still being very flexible/customizable, as well as tree shakable. Now supports virtually any size, and size ranges, have a base/default system which follows the ISO standardization specification (more or less anyway). It also adds pretty printing (including handling it both ways).
Note: This breaks backwards compatibility. It should be fairly trivial to add backward compatibility, at least using the new API (i.e. work with the old size table), by adding a new systems collection that is based off the old sizing table. I guess the API could also relatively easily be added as a separate function.
If you prefer, feel free to add me as npm collaborator/owner if you'd like me to handle pushing to npm and all that.
PS. Sorry for the last huge commit.