Move Unit.js into a standalone npm library #2739
Replies: 63 comments 1 reply
-
|
Sounds like a great idea. Not sure how difficult it would be. I'll give it some thought. |
Beta Was this translation helpful? Give feedback.
-
|
We could nab the @mathjs namespace on npm for it? |
Beta Was this translation helpful? Give feedback.
-
|
@harrysarson I guess we could, though I think it will be more powerful if Unit.js would become a really standalone library, and not sort of a child project still coupled to mathjs. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like a real challenge, but it feels like the right direction to take it. Where do we go from here? Do we create a new repo? |
Beta Was this translation helpful? Give feedback.
-
|
I think it involves the following steps:
|
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of making mathjs into a monorepl with one github repo containing multiple npm packages. Although this approach has downsides too. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it's also possible to spin multiple npm packages from the current mono repo. The reason I'm interested in separating Unit.js is that, like say I see the future of mathjs as being an integrated environment for mathematics in JavaScript: a "hub" merging a lot of different data types together (matrices, units, complex number, ...), and an expression parser making it convenient to work with mathematics in JavaScript. So, moving Unit.js (and also the Matrix classes) out of mathjs would help mathjs getting more focused, and will probably lead to an API that also makes it easier to extend mathjs with more data types (like typed arrays). |
Beta Was this translation helpful? Give feedback.
-
|
That makes a lot of sense 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I'll take ownership. Sounds like a fun adventure. That part I'm unsure how to do would be injecting other types like Complex and Decimal into the new units module. |
Beta Was this translation helpful? Give feedback.
-
|
Cool Eric 😎 There is no need to know all answers beforehand already, one step at a time. Have a look at the Unit.js file in the |
Beta Was this translation helpful? Give feedback.
-
|
All finished: https://github.com/ericman314/unitmath Just kidding, all it does is output |
Beta Was this translation helpful? Give feedback.
-
|
I just checked out the dependency mechanism in the Instead, perhaps it would be enough to just allow users (and math.js) to override |
Beta Was this translation helpful? Give feedback.
-
|
I've written a proposed API for the new library. If you like we can continue the discussion there: ericman314/UnitMath#1 |
Beta Was this translation helpful? Give feedback.
-
|
@josdejong, I've written a proposed API for extending the new unitmath library with custom types. Do you think that this API would work with mathjs? (https://github.com/ericman314/unitmath#extending-unitmath) |
Beta Was this translation helpful? Give feedback.
-
|
Man I love it already @ericman314! The API looks really clean and simple. I'm glad you go for immutable and factory functions instead of constructors with new :). I think your approach with custom functions I'm not sure about the name "extendType". maybe call it "arithmetic" or something? Or simply flatten the config, that may be cleaner and easier to remember, like About number/BigNumber/Fraction, etc: I think that the library does not need knowledge about these specific numeric types, but simply allow passing your own I was thinking about having all functions as methods, which doesn't allow for tree-shaking: that may not be an issue in practice since the number of methods is relatively limited and the implementation is small compared to the rest of the library. So please go ahead with chained methods as described in your proposal :) Are you still open for finding a nice fancy funny catchy name for the library? If so I will give it some thought. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying the multiple instances of |
Beta Was this translation helpful? Give feedback.
-
|
We may indeed need to adjust the unit tests of mathjs to the new way that unitmath works.
That's correct. I was able to remove most circular dependencies in I will have a more thorough look into the open issues you mention coming days, see where I can help. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I saw that trick you used in |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Another equally horrific solution is to make the unit wrapper a state
machine that keeps track of the most recent unit type and then coerce
future arithmetic operations to that type. Like I said, horrific. But if we
rule out all the bad ideas, the only left will be the right answer!
Your other ideas sound good. I think I will have time during the next few
days to work on it.
…On Mon, Jun 3, 2019, 1:29 PM Jos de Jong ***@***.***> wrote:
1.
About conv: it indeed feels dirty to provide this hint as to which
type to convert to, and the promoteArgs function also feels relatively
complicated. I think it will help to first resolve the other open ends, and
when everything more or less works, revisit conv and promoteArgs to
see if we can find a better solution.
2.
About comparison of complex numbers: I can think of a few directions
- Do we really need to compare (complex) numbers, or would it be
enought to uniquely sort them? In case of the latter, we could use
sortNatural from mathjs and pass that via the custom type functions.
- We have to implement wrapper around the custom type functions
comparing numeric values, so that they do "something" meaningful in case of
complex numbers instead of throwing an error.
3.
About toNumeric, toNumber: I think toNumeric is the better version of
toNumber, and we only need one of the two. Basically, we want to have
a way to get the numeric value out of the unit. Does that make sense?
4.
Fraction InvalidParameter: let's do some debugging.
5.
About configuration changes in createUnit: I think the most logical
here is to the factory function optionally dependent on on, which is a
listener that can be used for config changes. Just like
createUnitFunction does already. Search for occurrences of '?on' in
the code base.
6.
unit.exists does work, but the failing unit tests use Unit.exists, and
Unit is a wrapper around unit giving a deprecation warning that the
class Unit doesn't exist anymore. So this should be fixed when
changing the unit tests to use math.unit instead.
I'm not sure if my "trick" to expose the static method exists on every
unit: this probably breaks when you do any operation on the unit, which
returns you a new unit:
// expose static exists functionunit.exists = (singleUnitString) => unitmath.exists(singleUnitString)
This is a trick to get the static method exists exposed on a unit. I
guess that breaks when creating a new unit from the existing unit or so?
One solution would be to have unitmath expose the function also as a
method on every unit. Or else, in SymbolNode where we need it, we need
access to our unitmath instance.
7.
About creating a new unit from an existing unit: If this cannot be
done via the constructor, we could expose the factory function to create a
new unit on every unit, we could call it create(...) for example, like:
const unit = UnitMath.config({ ... })const a = unit('5cm')const b = a.create('2 inch') // create a unit without needing the unit factory function
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1486?email_source=notifications&email_token=ABQNHEPETQAKO5UCSKXNN7LPYVWJRA5CNFSM4HH52ZY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2OE5I#issuecomment-498393717>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQNHEPTZUR4TSQYN5DSYMLPYVWJRANCNFSM4HH52ZYQ>
.
|
Beta Was this translation helpful? Give feedback.
-
😂 that's the spirit. Yeah it's quite a challenge. It all feels to complicated. Maybe we need some sort of |
Beta Was this translation helpful? Give feedback.
-
|
Finally had some time to read through and respond to your comments above:
I wonder if a lot of these issues could be addressed by creating a new class in math.js that wraps every method of unitmath. It could expose whatever methods are needed for backwards compatibility. Every method call from anywhere else in the mathjs library gets filtered through this new class, so it can make sure the types are converted correctly. I'm not familiar enough with the new architecture to know the right way to go about doing that, though. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Works for me. I'll add |
Beta Was this translation helpful? Give feedback.
-
|
Ok cool 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Any update on this? I'm using mathjs specifically for the unit functionality, and would love to just use a separate library, if possible. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @jwir3! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @m93a that's exactly right. I had hoped to have v1 of UnitMath released long ago but extenuating circumstances prevented this. You can use the current version now, but some of the API may change. Specifically we're trying to simplify how users will configure and customize the library. So if you're just using the built-in units, and not adding any of your own, that functionality probably will not change much. |
Beta Was this translation helpful? Give feedback.
-
|
UnitMath is now v1.0.0-rc.1, feel free to give it a try. I would love some feedback before we lock in the API at v1.0.0. https://www.npmjs.com/package/unitmath/v/1.0.0-rc.1 |
Beta Was this translation helpful? Give feedback.
-
|
Four years later, the factorization of units remains stalled and we have unitmath at 1.1.1 and roughly twenty commits affecting mathjs internal Unit.js since 2021, so likely there has been significant divergence between the two. Does there remain a plausible plan for factoring Unit.js out of mathjs by using unitmath? What would have to happen for that to occur? I also want to mention a conceptual possibility for an intermediate factorization that could conceivably be easier: only use the external unit library, whatever it might be, for valueless units. Then there is no need to worry about what value type is being used in the unit class, or to have multiple instances that are using different types, etc. Then on the mathjs side, we have say a I suppose another possible approach would be officially to abandon this effort to factor out units, and let unitmath and mathjs just continue to evolve in their separate ways. Just some thoughts... |
Beta Was this translation helpful? Give feedback.
-
|
Interesting idea, Glen! Using only valueless units could make the integration simpler. I can't really say for sure because I have been out of the loop for so long. And I'm sorry for not being more involved. Programming used to be a hobby for me but it's my career now, and between family and everything else I just don't have time to work on personal or open source projects any more. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Just floating an idea here: the
Unit.jsclass is a powerful piece of functionality on it's own, separate from math.js. It could be interesting to think about splitting it from math.js into it's own npm library, similar to the libraries Decimal.js, Fraction.js and Complex.js used by mathjs under the hood. Of course Unit.js should keep it's injection of methods likeadd,multiply,Complex, etc to keep it flexible and integrable).What would we gain with it?
@ericman314 do you have some thoughts in this respect?
Beta Was this translation helpful? Give feedback.
All reactions