Closed justinbmeyer closed 6 years ago
The Safe
way seems like the "right" way, where we won't be causing a mess for ourselves to untangle down the road.
But it will force a CanJS 5.0.
We're not really running out of integers
My vote:
A bunch of CanJS code assumes the existence
Where? I'm surprised that any canjs code cares about this other than can-connect...
I'm surprised that any canjs code cares about this other than can-connect..
@matthewp is right, actually, that is probably the problem we should "solve", making sure a bunch of code doesn't assume there is a can-set/can-query
I meant a bunch of can-connect
code. And it doesn't just assume an algebra is passed to it .... it assume the presence of a "default" algebra.
completed for CanJS 5.0
For CanJS 5.0,
can-query
will be the default instead ofcan-set
. This issue discusses how to removecan-set
as a dependency and replace it withcan-query
. There's a few options, but first the problem:Problem
A bunch of
can-connect
code assumes the existence of acan-set
algebra or creates one if one doesn't exist. For example, in real-time:This makes it so we must have some form of
algebra
available by default. This means importing an algebra.Dangerous, but possible
can-query
has a compatibility mode that passes allcan-set
tests. We could simply import that, and use that as the default algebra.It's likely this will cause bugs during an upgrade, but we can fix these. Eventually,
can-query
can be fully backwards compat.Safe, but slow to discover compat bugs
Alternatively, I can start working on
can-connect@3.X
right now. Have it usecan-query
everywhere, and if people want to upgrade, they change:To
Everything else should be the same.
My Preference
I think I like the
Safe
option because it will mean less over-all work for me. But it will force a CanJS 5.0.