Version 2 beta & feedback wanted...

Velocity is finally getting a lot of love and updates, sadly it’s also going to lose support for older browsers (I’m planning to make a compatibility layer with polyfills for them, but that’s low priority).

See the Project or the develop branch 😃

Among other things, it is already converted to Typescript (that means nothing to anybody who isn’t developing for Velocity directly - but looking at the code should show how similar things are).

It is also losing the requirement for any jQuery stuff - currently there’s a shim for what we use, but that is being replaced by native calls and custom code.

The API for extending it is getting expanded and improved (and hopefully getting easier to use too). I’m planning to make use of the wiki on here, and there will eventually be the website on another branch (ideally built automatically from source comments, but will have to see what I can do).

I’ve linked quite a few open issues into the new project as I have a definite end goal for what’s needed before release - but this is where anyone still reading this is needed:

Current TODO before anyone else can help coding

I’ll remove this section once it’s done - but as I don’t want to push anything that breaks the tests I might have to take a day or two with in-progress major changes that I can’t easily pull against. Saying that, code snippets etc are very welcome and I can fold them in manually 😃

• Finish build environment (NodeJS and Grunt)
• Split out the .CSS section.
• Fix SourceMap generation (only for non-minified version).
• Remove jQuery shim.
• Split apart the main Velocity(...) function - it’s still a couple of thousand lines long!
• Finalise folder structure / file layout.
• Finalise Velocity extending API (even if code not finished).

I need your help

Firstly there is testing. While I’ll make sure that the included tests are all succeeding before each push, they do not cover enough uses, and can quite easily miss things (yes, that’s also TODO, but not as high priority - plus some tests need to change due to internal changes anyway).

Things to test

• By default the beta patches jQuery, Zepto and native elements, as well as the native element finding methods.
• It also makes sure that anything returned can be chained via .velocity(...) (as jQuery used to etc).
• It also always includes the Promise too.

In other words, this is now valid -

document.querySelectorAll("div")
   .velocity({opacity: 0})
   .velocity({opacity: 1})
   .then(function() {
      console.log("Muahahaha!");
   });

Things to comment / ask in here

• Anything not on the Project page that already has an open issue (no, I’m not blanket adding, I will go through them afterwards and remove the ones that are fixed as a side effect etc).
• Anything not on the Project page that would be useful to add (for example, I’ve been looking a bit at the Web Animations API.
• Clarification on how things are changing (don’t worry about bad questions, I’d rather answer something seemingly obvious than forget to mention in).

Things not to ask

• Is Velocity v1 being updated to fix xyz? (The answer is no, I’ve made significant progress in bugfixes and improvements that I hadn’t even noticed were wrong simply by refactoring to Typescript, and the amount of time I’ve spent is equivalent to fixing a single “easy” bug in Javascript)

[Rycochet]

So it’s nearly time for a public beta!!!

At some point over the next two days I’ll be branching the current code into a v1 branch, then merging the develop branch back into the master branch. Finally I’ll promote an unstable Release for “2.0.0”.

There is one major(ish) part not done yet - which is far more to do with designing an updated API when other things are public - and that part is the old UI Pack. The reason it’s being held back is that I want to make it possible to treat a single effect as a single animation - and be able to scrub to any point along it in a simple way. The old UIPack basically chains animations that are each separate and only have a single duration that’s shared. When there’s been some feedback and bugfixes, it should give a clear indication of where to go with that.

So 2.0.0 is going to be the public beta. I’m not going to suffix it, but will increase the last digit, with 2.1.0 being the full public final version (and not marked as an unstable release any more). I don’t know if the UIPack code will go in by then, as it will largely depend on both time and design (I am aiming to get it done). In terms of timescale, I expect this to be around the beginning of March, but it is dependant on coder availability.

In the run-up to this update I’m currently fixing some final tests, which is (hopefully) fixing the last obvious bugs (going to be up to you lot to report things as they’re found). I’m also putting together the wiki pages on here, so the documentation for v2 will be purely wiki until it’s final release (thanks to Github I can do that all via git too, so it will be updated as a single push). As part of that effort I’m also making some final minor fixes to the major API updates.

I will add a CHANGES text file with the major changes from v1 to v2 (there are quite a few for advanced use, but simple use is almost the same with the exception of scrolling).

The source code is now both self-documenting, and well-commented. There’s still quite a lot of places it doesn’t have enough (or isn’t updated to v2 formatting standard) - so things like that are also good to be updated (we’re open to Pull Requests once it goes public beta on the master branch).

Oh, and one thing that made it in since the last update - the internal code is now a lot closer to being able to animate arbitrary Objects… Doesn’t mean much to many people. but it does mean that it could be used for more games and visualisation tools that aren’t HTML based…

[Rycochet]

Thought it was about time for another update (does anybody even read these things?), so here we go 😃

Velocity2 is getting closer to public beta testing!

Internally a lot of bugs have been squashed, and a lot of code has been replaced, and we have several APIs ready for use in the real world. While there’s still several things to be done over the next week or so, we’re starting to get onto the updating and fixing the tests (required so we can ensure that things are behaving as expected).

We now have an API for extending "actions". Yes, those things that are passed as a string instead of the properties.

An action function is defined as:

function myAction(args?: any[], elements?: HTMLorSVGElement[] | VelocityResult, promiseHandler?: VelocityPromise, action?: string): any

• The args are the arguments supplied (so Velocity(elements, "myAction", 1, 2, 3) would get [1, 2, 3] passed as an args array).
• The elements are passed next (it needs to handle no elements for when passed as the first argument of Velocity - such as "finishAll" etc) - because it can be chained you can check for a .velocity member on it, and if it has one then it should have a further .animations element within that, which is an array of the animations added by that previous call.
• The promiseHandler is there so you can resolve or reject the associated promise (if valid) - useful for reporting errors back to whatever is using it.
• Finally the actual action string is passed. This is useful as the registered action itself is the part of the name before any dot ("."), but this is the entire string - so for instance passing a queue via "myAction.myQueue".
• The return value can be anything you wish to return, or simply return undefined (return; with no arguments) and it’ll allow the call to be chained to another velocity function.

There’s also a vastly improved argument parsing code in place - it saves as much time and memory as possible by not parsing things unless it actively needs it.

The number of open issues relating to V2 is going down pretty quickly, and I’m hoping we get a lot of them closed once we have tests written for them 😃