Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Version 2 beta & feedback wanted...

See original GitHub issue

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 -

   .velocity({opacity: 0})
   .velocity({opacity: 1})
   .then(function() {

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)

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:3
  • Comments:20

github_iconTop GitHub Comments

Rycochetcommented, Jan 29, 2018

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…

Rycochetcommented, Nov 12, 2017

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 😃

Read more comments on GitHub >

github_iconTop Results From Across the Web

Overwatch 2 beta feedback - General Discussion
Queue times are still horrendous even for a closed beta. This is simply unacceptable. Priority queue an illusion. Heavily favors support roles.
Read more >
OW2 Beta Feedback Megathread + FAQ : r/Overwatch - Reddit
Blizzard seem to want OW2 to be more mobile and dynamic. I think I'm on board with that idea, but reducing it to...
Read more >
A Modern Warfare 2 Beta Feedback Review - YouTube
So, The Beta has concluded for Modern Warfare 2 today and with that, it means we now have a little over a month...
Read more >
Modern Warfare II Post-Beta Review & Feedback! - YouTube
The Beta for Modern Warfare II has ended and today I wanted to share my thoughts and major points of feedback based on...
Read more >
Overwatch 2 Beta Feedback Will See Symmetra Buffed ...
As outlined in a new developer blog, an upcoming beta update will look to buff Symmetra and bring further changes to Mercy's Guardian...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found