johnpaulharold / crt Goto Github PK

Investigate if a basic signals implementation can be added

See https://www.lksh.dev/blog/writing-your-own-reactive-signal-library/
also https://www.solidjs.com/tutorial/introduction_signals

Resources:

https://github.com/HbbTV-Association/Tutorials/tree/main
https://developer.hbbtv.org/tutorials/hello-world-application/

Quite often with carousels on TVs, the component will not start scrolling until some later child child element.

For example, a horizontal Carousel, where the focus is on the first child item, user moves right another two items and then scrolling only starts after that. As an API, it might look like

<div deadsea-orientation="horizontal" deadsea-scroll-start="2">

Add a type which expresses the types of HTML Elements

See https://developer.mozilla.org/en-US/docs/Web/HTML/Element

The kind of layout you see for Films, TV series.

dealing with loads of classnames is a chore. Libraries such as classnames help, but are a bit much.

https://github.com/JedWatson/classnames

Instead, we could use something like this https://github.com/alexnault/classix/tree/main, which is much lighter, and faster and for now, ES5 safe.

As the classix lib itself is liberally licensed, and is just an efficient for loop, I'd rather just copy and attribute the code and provenance in the repo, rather than pulling it in as an npm module.

It could be practical to offer an escape hatch for when the default handleKeyDown method that integrates with lrud-spatial isn't enough.

This could be a starting point

https://github.com/HbbTV-Association/Tutorials/tree/main/screen-logger

MIT license, offered by the HbbTV org

This repo starts from already existing code, so the first commit will likely be the dump of all that.

For example, switching view. When the view has loaded, focus is assigned to the first candidate in the view scope.

A common pain point with performance on TVs and STBs is creating and managing DOM with lots of JavaScript. Some of this DOM construction is unavoidable and makeElement() helps with that, but some could be avoided and skipped if the server just gave us the HTML already.

If this sounds familiar, then I guess it's how websites used to work, before single page apps became a thing and servers were reduced to being dumb data stores. The key difference is, we want to avoid reloading everything else, like a regular web app with different routes, and instead add and remove large-ish fragments of HTML and carry on scripting against those.

Yes, still sounds familiar.

Something that does this, https://canivideo.com/

Logic can be found here, https://github.com/bwallberg/canivideo but could be adapted

MIT license

It was added while trying fixes for ancient Humax device, but it might not be needed.

Test:

• remove it
• test on Humax device

Investigate strategies for handling back button behaviours.

It could be that a custom history stack is required, where two types of objects are pushed:

• routes: /path/to/route: { type: 'route', value: 'path/to/route' }
• focusables: #idstring: { type: 'element', value: '#idstring' }

and then a backKeyPress handler takes what's at the top of the stack.

The stack could be just that, Stack type class, with usual methods for management on it. Each change on the stack calls a change handler, and then it's up the view to handle what it should do (move focus around, navigate away, exit the app etc)

Also, the concept of certain destinations acting as slate cleaners. Such as, your main/top navigation. Any focus into that would signal to the back journey lib that the current stack can be cleared

Probably use Playwright for this. See https://playwright.dev/