Behaviour of "stop" Lifecycle Event changed about katavorio HOT 9 CLOSED

the object passed to the stop event callback has a selection array in it, which contains the id and new position of all elements that have moved.

from katavorio.

First thanks a lot for the very fast answer!
Sorry I did probably not really bring the point across what my problem is. I do not have a problem getting it to work with the new behavior. It is already working fine again (even though my code is now much more complicated and ugly). The problem I have is that it is a breaking change and breaking changes should not happen in a minor version upgrade. And now looking into that some more it seems it even must have broken from 2.8.0 to 2.8.1 which is only a bugfix version change where really really no breaking changes should happen. And if there is no way around a breaking change and for some reason, a major version upgrade is not possible at very least I would expect very clearly stated somewhere that feature X will work differently now (but then also only in a minor and never a bugfix version).
Please do not understand me wrong. Jsplumb and katavorio are really great projects and I am incredibly glad that they are there. They normally also work perfectly fine. But for me (and I am also sure other people) it is important to know that code does not simply break. I, for example, was for hours sure that I must have broke something as I knew I did not make any changes to the jsplumb version in months. It did not even cross my mind for that time that such a crucial behavior would knowingly change.

from katavorio.

i wouldnt have bumped the version to 3.x.x for such a small-ish thing. and i certainly do not recommend people blindly allow npm to take control of the libraries upon which they depend. you should pick a version of something, test it, become confident with it, and stick with it. when you want/need to upgrade, pick a new version, test it, become confident with it, stick with it. etc.

why is your code so much more complex with this change? why not just register some new "stop" function instead of your current one, and inside of it iterate the 'selection', calling your current one.

from katavorio.

I would say it is a common pattern to not set a specific version for every package. Especially for bugfix (patch) versions. As they normally supposed to never break anything and just fix bugs. Even more when in active development phase like I am right now (one of the reasons why I thought I was the problem). Sure for production-setups that is something totally else but also there it depends a lot on the application and the size of the company and so at least the bugfix version does not always have to be fixed.

And it is not really of the size of the change it is simply about if it breaks stuff or not. Here is the official npm-page about that: https://docs.npmjs.com/about-semantic-versioning
There it states for both patch & minor clearly backward compatibility. And that is exactly what people expect from npm packages.

So would be great to know that at least bugfix versions are always backward compatible in the future. And if breaking changes occur that they are clearly documented somewhere. Think especially for an Open Source project that is very important.

Why it is more complex: The reason is that I use it with Vue and I have a node-component (for each draggable) where each node simply takes care of itself. Which was easy because each dragged node got their own "stop" event and so could easily do that. Now not so nice anymore as only one node gets the "stop" event for all of them and so also has to take care of other nodes.

from katavorio.

the notion that it's a common pattern to not set a specific version for every package doesn't have any bearing on my opinion on whether or not it's a good idea. i am also not swayed by what someone at npm wrote on their "official page". it simply isn't a good idea to leave dependencies up to the vagaries of the universe. it's irresponsible.

shall i close this then? your app is working?

from katavorio.

Yes, you are totally right. It does not mean it is a good idea just because everybody does it. And I am not really saying it is either. It is probably not. In a perfect world, the versions would be fixed and we would check every day if there are bugs or security issues found in any of the packages used and then update them and check the whole application if everything still works. Sadly is that not always feasible.

But just because it is maybe not a good idea does not mean it is not worth supporting anyway especially when the community expects it to work that way.

And there is a good reason to follow this versioning no matter what, even if the whole world would use fixed versions in their package.json file.
Here what they write on the page:
"Following the semantic versioning spec helps other developers who depend on your code understand the extent of changes in a given version, and adjust their own code if necessary."
If people do that I can see within a second if the upgrade will to 2% break anything (bugfix, because also bug fixes can introduce new bugs) or to 10% (minor, as they are still larger and could still break stuff even if not intended) or lets say 90% with a major one (the numbers are now totally made up but feel roughly correct).

And you are also right that it is some kind of irresponsible. But to be honest the whole idea of npm and using code from strangers is totally nuts and dangerous (even more because the dependencies have dependencies and so on). No matter what it is, in that case, the decision of the person and their own project. And if something breaks it breaks their own product. When however an Open Source package with over 8k people downloads per week uses random-versioning (no idea how it is really called and if there is a name for it) and does not even mention it anywhere it is much more irresponsible in my eyes because then it breaks other peoples products.

It is your project and is like I said really great and helpful. And you can obviously version it however you want. But I, and are also sure other people would appreciate when it is somewhere mentioned that semantic versioning is not used and that EVERY version change can include breaking changes. Also, a proper changelog where every breaking change gets documented would be great. Because did for example not find any mention anywhere about the change to the "stop" callback when used with a selection.

And I really not just saying that to complain. I am now aware of that and so I know that I have to be extremely careful. But other people are not. Especially people which start to use it now or in the future (and maybe even people like myself which already use it for a few months). So I think it would be nice to make them aware of that. Thanks!

Closed the issue myself even though I think the stop callback should still be called multiple times like it does for the other two (not just because of my code also because it is simply inconsistent and so confusing).

from katavorio.

i don't think i'll be able to reinstate the original stop callback behaviour. but i will switch to strict semantic versioning for the Community edition of jsplumb and its associated projects.

from katavorio.

Really great to hear. Thanks a lot for that and also the work on the library in general! Have a nice weekend!

from katavorio.

you know, after thinking about this a while, i don't think I will in fact be switching to strict semantic versioning. i don't agree with it, specifically with the limitation that breaking API changes must result in bumping the major version.

from katavorio.