ryuuart / manawave Goto Github PK

There may be use cases where cloned HTML will need to be operated on by some external library or function. Other use cases also include support for event handling and other operations on the raw DOM. We can expose the raw HTML for selection, usage, or modification for folks who need to use libraries or other JavaScript to add customized behavior to the clones.

Items have unique statuses defining events / triggers that occur over playback.

Right now, both are intermingled in TickerItem which really should be a common interface between both. What I propose is to create a RenderItem and LogicItem for the Item and extend off those base classes. This may change, but the overall goal is to be able to separate what should be logical or render operations.

For example, setting the style of a DOM Element, to me, counts as a render since it updates on the screen. A position that's tracked separately will then be used to update the style of the DOM element. This is a logical operation. The reason why we're being more explicit about this is because right now, updating position also clashes with trying to discern the logic of things.

We're basically trying to solve this problem.

It should be DOMHighResTimeStamp

The autoplay option should be respected.

I have all the parts to build up a System now. It serves as an intersection point for different responsibilities that essentially animate and output the system.

Users can create custom CSS on the slider and depending on if it's a flexbox or something, it'll break. We want to make sure that CSS can't leak and affect the behavior of the slider.

Allow fine grain control to slider like play and pause.

• Play
• Pause

Can't have a Billboard Ticker if it doesn't animate. An animation controller is necessary to animate TickerItem. It's important to note that animation only refers to the ability to animate given a TickerItem. The scope is only towards basic animations and nothing more like looping TickerItem or other advanced functionality.

Why? Because it's unknown how Parcel interacts with other components that use Vite, and also because I personally feel it gives more control. Also, because WDIO uses Vite in their browser runner so to keep the codebase more concise and unified, going to move to Vite.

So folks can begin to use the library for their stuff.

Also to set up this repository on their system.

Given an HTMLElement or id, remove the TickerItem. Also add the ability to remove a list of TickerElement too that should be in a separate function.

Right now, implementing System relies on coding specific yet repetitive logic to test the current state of playback and other stuff. It's pretty error-prone to rely on making sure each of those variables are manually guarded and implemented. Instead, we should bake or "decorate" this behavior in anything that needs it so if there are bugs, it's not distributed across all System.

Typically in a physics simulation, you pass it time and deltaTime to advance the simulation and state. Our interactive / dynamic TickerSystem, while not a physics simulation, does rely on time to advance its state and behavior. We want to move from using AnimationObjects to a registration system. The AnimationController becomes a singleton which pools all update and draw calls in the render loop (this is more performant). The registration would register systems one-by-one. The render loop would then go through each system and apply relevant update and render (this sounds like what a queue would do) to progress state.

This would likely eliminate AnimationObject. I actually felt like it was parallelizing TickerItem regardless and confused what is responsible for what. This functionality would be replaced with #30.

We'd probably create a System superclass with relevant draw and update calls. TickerSystem would extend this base class.

AnimationController would turn into singleton, using static for most operations

Width and height are shared traits across the entire system. These should be referenced elsewhere.

Depends on #44 .
It should be possible to start, stop, play, and pause a given system or the whole AnimationController. It should be possible to define what happens for each operation in the System but also retain the logic and state provided by AnimationPlayer.

Playback exists on System, but is limited for Controller.

Given measurements, create a container of items that can be operated on. This is going to be used to store and contain TickerItem more logically. The naming and convention is more logically aligned with what is happening on the DOM.

Currently there's no way to retrieve and analyze a subset of TickerItem from the TickerSystem.

It seems that Vite supports CSS modules and that would be much better than the custom injection script that is run. Mostly because it would be unlikely that users use the same CSS class names.

Currently, there's a lot of code smells and it's needed to reshape and organize the code.

Right now, resize involves completely deinitializing and re-initializing the entire Billboard. This can
layer up fast, especially in nested Billboard situations. We should split from a complete hard reset, and only do work that is necessary during a resize. Right now, I see dimension measurement and adding new TickerItem to be the main issues here.

Basically, the only thing we're laying out and is unique to every element is its position. The dimensions are fixed and shared across all objects. That's why we instead move the width and height into a GridOption object.

Right now, if you're not using a web-component, you need to use JS to initialize the Billboard. This breaks a layer of immersion and magic with just writing HTML to make marquees just work. You should only need to include the script tag and everything else should just follow. I'm suggesting adding in a data tag on the div to just make it work from the HTML.

There should also be a way to disable this behavior. We want this library to not create ANY side effects on the rest of the system. We want a Ticker to be just as self contained as the HTML version.

There should be a way to turn on and off the slider without being destructive to its original elements.

There's also a difference between pausing, creating, and destroying.

The example pages are meant to test the Ticker naively outside the contexts of Tests and source code — as if we're using the library live in a bunch of contexts. Right now, these example pages are a bit stiff and unable to express this intention, so they need to be updated.

Test Base.clearContent should only clear the relevant content. If everything should be removed, there should be a method called "clearAll".

Right now, dimensions are needed to position and layout TickerItem. It's currently done by adding the TickerItem directly into Ticker, appending it onto the DOM at some far off position(-9999, -9999). This makes sense, but will eventually turn into tech debt if there is a screen large enough to visualize the "far-off" position.

It turns out I was writing integration tests this entire time and we need unit tests for both of these cases.

There should be a way to overlay and build on the default animation and position.

There should be reasonable defaults to configure the behavior of the slider like:

• Target
• Direction
• Speed

When a System is registered, it should also be deregistered ensuring that all things related to the System are removed and cleaned.

This will take some figuring out, but everything should be updated before drawing. Especially for #34 .

Right now, we only have position to query and observe the TickerSystem and its TickerItem. I'm proposing more properties like lifetime and timeCreated as another. This will let methods like TickerSystem.queryByCondition() to be more flexible.

If there needs to be an update or refresh for any reason depending on dimensional changes, there's no mechanism to handle that change in state.

Add functionality for TickerSystem to add a new TickerItem. It shouldn't be visible until loaded, and if Ticker is loaded, then it should directly be added into the Ticker. Also, should be able to add a list of TickerItems in a separate function.

Right now, we have one object that handles too much. We need to start splitting functionality and concerns to make sure our code is readable, predictable, and extensible.

• Use Motion One
• Use Web Components
• Start storing State

Performance is immediately an issue with these Tickers animating so many things at once. A good performance optimization is to only run updates only if a Ticker is in the viewport. This will need to IntersectionObserver be integrated into the TickerSystem. It basically should call the pause() function appropriately.

There is major layout thrashing during the initialization phase of the Ticker. We need to offset measurement to occur only during initialization or resize. Resize will likely be handled in another issue.

This was revealed when you use a nested webcomponent Billboard. It seems that logic in that webcomponent is leaked to the rest of its cloned descendants. We need a way to ensure that when cloning occurs, state remains separate no matter if it's because Billboard webcomponents share state or some other library share state.

This has already been done in a previous rewrite, but now we need to do it again in this rewrite.

You should be able to return the Ticker to its original, unanimated state if desired.

Add ability to measure rendered DOM.

Long story short, the code knotted itself so it's hard to go forwards. Rewrite time!

I realized… after trying to mess with the architecture some more, it might be not do-able. There is too little usability and configuration allowed by this architecture :/ I think it's going to need to go RIGHT BACK TO THE DRAWING BOARD… at least most of the logic is already done I guess… it's not exactly ideal if you must know.

I hate re-doing stuff like this, but there are several problems with my codebase.

1. using builder to create more problems rather than solve one
2. state introduces unnecessary overhead and again, doesn't serve a purpose but to just exist
3. there is unncecessary data-flow causing the codebase to splinter and work against each other instead of a modular cohesive unit
4. the codebase is inflexible, making a regression break things heavily
5. new requirements were discovered while working on the codebase… I think I should've spent more time thinking about the various uses of this, not that I knew ahead of time lol

Currently, when the window is resized, it breaks responsiveness. Resize operations should not affect the marquee, but it does. Since I plan on restarting this entire project over to use paths instead of a CSS dimension hack, this feature can be supported by either destroying the ticker and restarting it (maybe a debounce is required), or by recalculating and reinitializing the ticker.

These are currently very heavy and should compose of parts more. Even the code is more verbose, it's more important that responsibilities are separated.

I want to, given an HTML block element and ID, make a square div inside repeat.

Right now, this will either be my 3rd, 4th or 5th rewrite of this code. This time, I know exactly where things are supposed to go, so it should go very smoothly this time. I have the MVP, I just need to move from inheritance to composition codebase. I'm doing mostly because I feel uncomfortable with slapping together a codebase and allowing it to be contributed on. There's a lot of noise in it, and I'd like to reduce that noise into a clear, concise voice. This final reset will be documented and properly unit tested.

Right now, each test wipes out the document body, including webdriver's additional scripts and configuration. It may be preventing webdriver to work properly and hinders the debugging experience.

Right now, the cloned amount is hard-coded and should be declaratively reacted. For the first phase of this task, the focus should be on differing static widths. Likely multiple marquees of different lengths and elements of different sizes would need to be created and explored here.