React-based UI rewrite

[scottlamb]

The web UI has plenty of deficiencies: poor error handling, no scrub bar (#32), no live view (#59), no support for the "signals" schema (#28) or any kind of analytics, no configuration (#35), not very pretty, etc.

I don't think the current jQuery-based implementation is a good foundation to fix these problems. The cool kids haven't been writing jQuery in many years. I've tried out React and see why it's taken over—its well-defined component lifecycle and declarative style make it easier to build reliable UIs. There's even a fairly good story for testing.

My goals for a new UI are:

• avoid spending Moonfire NVR's "novelty points" needlessly. I was more bold with server-side choices (using Rust, the storage schema and custom .mp4 generation). I think popular, well-documented, well-supported frontend technologies will be fine. They'll lower the barrier for contributors.
• make it easier to build the parts of the UI I want (see above) from components.
• good usability, including a polished appearance and proper error handling.
• less important: minimize the code bundle size. I looked at Preact (which is noticeably smaller) but the API is just different enough that some docs might not apply, it might not be as well-supported, it might lag in features, etc. Other frameworks like Vue, Svelte, and Flutter might be fantastic but I want to stick with something pretty mainstream.

so I'm trying a new UI based on React, material-ui, TypeScript, and testing-libraries.com. (The tests run on Node now. I'll likely need tests on a real browser to test HTML5 Media Source Extensions functionality and such but I'll save that for later.) It uses create-react-app and tries to follow its recommendations.

I've already been playing with it for a couple weeks and will start committing to a new-ui branch shortly. The first commit won't do much (just the project structure and ability to log in and out, but no ability to view video). I think I'll add in a list-based UI to match the current UI's functionality next, as it'll be quicker than building a scrub bar thing. Once I match what the current UI does, I'll merge it to master.

[jor3l]

Do you need help with the UI? Lmk

[scottlamb]

@jor3l Short answer: yes, I'd love help with the UI!

Longer answer later; I'm taking care of my sick daughter + online kindergarten son right now.

[scottlamb]

@jor3l Sorry for the delay before my longer answer. My daughter's feeling better!

What did you have in mind for help? I'd gratefully accept about any type of help—from constructive criticism and ideas to PRs fixing small problems to even PRs for the bulk of the UI. The biggest constraint is that it has to be something that I (and ideally other people) can continue building on. That's what I'm aiming for with the choice of popular Javascript building blocks. (I'm open to exploring alternatives to some of those things, but the alternatives also have to be popular / well-documented things likely to stick around for a while.) Also, it's helpful to coordinate anything big with me ahead of time so we don't waste effort.

Are you able to run the new-ui branch's development server now? It works for me on my laptop, and (as of fbaf751 yesterday) on my workstation. There are some tests which (as of 2677184 yesterday) are also passing for me and on CI. Hopefully that all works for you too; please let me know if not. The UI still doesn't do very much; it just lets you log in and out.

I have the temporary list-based UI in progress in my client. I'll try to get something committed today to build from. It's likely to be not very pretty and somewhat broken but I figure that's better for collaboration than waiting to share until I've reached perfection (if I ever do).

[jor3l]

Hey! Glad to hear that she is better now!

So I'm setting up a smart home and got some IP cameras, I need-want a dashboard that also has object recognition and alerts. That said I'll give a try to your project and see how it works with my cameras, I think that having this with an API based approach is awesome, anyone can build a client for it. I'll check what you have for the UI and either improve it or get a standalone ui working with your server. Let me check this project out first and do some tests and I'll let you know how I'll help.

[scottlamb]

My list UI draft is on the new-ui branch. It's missing some things the original UI has, like trimming the recordings so they don't extend beyond the selected time range. But in quick (manual) testing, it seems to basically work.

[scottlamb]

I think it's about ready to replace the old UI. It actually has decent error handling, even some automated tests. I think it looks more polished. It should be much easier to extend; I'm looking forward to adding new functionality. And it feels pretty good in my manual testing.

A few quirks:

• the display isn't as dense as before, even after I overrode some options to make it denser than default. I'm on the fence about this.
• the date picker's "today" is based on the browser timezone, not the server timezone. It wasn't immediately obvious to me how to fix this. Maybe it requires overriding the localization provider?
• the time picker doesn't allow picking the once-a-year "fall back" hour, even via the old hack of overriding the time zone offset. Likewise, overriding parsing of the text entry field didn't seem particularly easy.
• the time picker also is off by an hour after 3am on the "spring forward" day (two days ago in my time zone). This probably is easier to fix; I just haven't done it yet.
• It no longer opens video clips in a draggable/resizable dialog (desktop) or completely full-screen/landscape (narrow screens like my phone in portrait mode). The former isn't supported by material-ui, and I think wasn't that great anyway. You could open multiple videos at once but it wouldn't actually play them in sync. As for the latter, I found it a little too quirky. Full-screen mode exits when you change apps, and my old event handler would close the video then, which means you'd lose your position. So instead it just opens the video to use as much of the window as it can. You can of course go to true full-screen yourself. You can close it by clicking outside the video or hitting escape.
• in the lower left, the "Max video duration" shrunken label has a line through it. It doesn't seem to properly blank out the portion of the select field's outline. This might be a bug in the material-ui alpha I'm using. fixed with 76ef6e5

[scottlamb]

Oh, the date picker is missing some CSS to make it smaller on desktop. Looks like it broke with d273a99. I'll have to fix that. Fixed.

And the video sometimes flickers somehow on mobile—the element gets briefly larger then smaller again. Not sure why. Looks like this is unrelated to the new UI. It's an Android/Chrome bug that happens when I'm playing an <video controls src="..."> element with the controls visible (eg shortly after touching it) and I'm debugging that Chrome tab (with a USB cable + desktop computer via chrome://inspect). It sometimes shows the thing under the video, whether that's other parts of the webpage or (when in fullscreen mode) a completely different Android app. This happens even with a really basic HTML page.

[scottlamb]

Bit more dense. I just reverted d273a99, so I don't have the secondary color I want on the date picker. 😩

[scottlamb]

I think it's ready to switch over, except that I'd like to improve the time range problems mentioned above. I'm a little stuck on doing so properly; I asked on stackoverflow but got crickets. Help welcome...

[scottlamb]

I'm just going to accept imperfection for the moment on the timezone stuff. It's an improvement overall, including the new live view UI. Now merged to master and released as v0.6.3.