Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.0.0 planning #41

Open
jeremyckahn opened this issue Oct 21, 2015 · 3 comments
Open

2.0.0 planning #41

jeremyckahn opened this issue Oct 21, 2015 · 3 comments

Comments

@jeremyckahn
Copy link
Owner

Some parts of Rekapi are starting to feel a bit crufty, so I think the time is right to start looking at a 2.0.0 release. As per SemVer, this version would introduce breaking changes. Rather than introduce a plethora of sweeping changes, I'd like to focus on addressing Rekapi's key pain points with regards to using it and integrating it into a project. I'd like address three themes for 2.0.0:

  • Eliminating the Underscore/Lodash dependencies
    • This means dropping support for older browsers. Rekapi 2.0.0 will only support evergreen browsers.
  • New event system. The current system is overly simplistic and inflexible. Currently, all events are routed through the central Rekapi instance, but this means that events aren't fired from a detached Rekapi.Actor or Rekapi.KeyframeProperty. I'd like to adapt some patterns and APIs from Backbone to improve this.
  • API consolidation and cleanup. Rekapi's API has a number of weird quirks and inconsistencies. Most of these were introduced to maintain backwards compatibility while adding new functionality.
    • modifyKeyframe and modifyKeyframeProperty are examples of APIs whose method signatures make no sense in the context of each other. They should be made to be consistent.
    • removeKeyframe and removeKeyframeProperty are examples of methods that could just be one method instead of two.
    • Many of Rekapi's APIs could benefit from using configuration objects rather than ordered parameters.
    • Additionally, I'd like to shift from "animation" semantics to "timeline" (for instance, Rekapi#getAnimationLength should be Rekapi#getTimelineLength).

I'm opening this ticket as a means to solicit feedback from the community. What would you like to see in Rekapi 2.0.0? I'd like to constrain the conversation to improvements rather than new features. Please let me know what you think!

As for when this might get done, I'm working on some features for Stylie and Mantra (which are driving the need for Rekapi 2.0.0), but once those are done, I should have the availability to focus on Rekapi again. Of course, help is always welcome. :)

@jeremyckahn
Copy link
Owner Author

I never got any community feedback on this, so I'm going make decisions based on my own project needs. For 2.0.0, I intend to completely rewrite Rekapi from the ground up. This will involve many architectural and conceptual changes from what Rekapi is today. In my projects, I use Rekapi as a timeline data model. I plan to streamline Rekapi for this use case as much as possible. Here are some of the changes I would like to make:

  • Redux-based architecture
  • Mocha-based unit tests
  • Written in ES6 (via Babel)
  • Flattened data structures: Instead of Rekapi, Rekapi.Actors, and Rekapi.KeyframePropertys, there will just be Rekapi.

Because 2.0.0 is going to be so different, 1.x will be maintained on an ongoing basis in a branch once 2.0.0 is complete. Until that happens, 2.0.0 development will take place in the 2.0 branch.

@YoSev
Copy link

YoSev commented Oct 18, 2016

Hey,

i am using rekapi to overlay videos with tracked clickable markers and i love it.
The biggest problem for me is to sync an animation/timeline with a HTML5 video element.
I would love to see a sync method, if not live (which is kind of impossible, i guess), at least at certain ticks/ms.

Keep up the good work!

John

@jeremyckahn
Copy link
Owner Author

Hi @JOHN-DEV, thanks for the input! What you're working on sounds really cool. I feel like the functionality you are describing is a little out the scope of what Rekapi should be focused on. However, it is the sort of thing that should be facilitated by Rekapi (as in, the library should be flexible enough to make video syncing straightforward to implement).

If you'd like to discuss how that might be implemented externally to Rekapi, please open a new Github issue on this project and I'd be happy to discuss it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants