Improving the Front-End

[alsoLut]

While I like that the front end is framework agnostic, in my humble opinion the code isn’t where it should be. Several improvements should be considered: adding TypeScript, introducing encapsulation via Web Components, and implementing page routing.

[starkjohann]

I agree to most of that (except page routing, at the moment it's a single-page app where we don't need any page routing). However, I have no expertise in JavaScript, TypeScript and the frameworks offered. The entire code is around 7000 LoC at the moment, not too much to refactor or even rewrite. If anybody wants to volunteer, improvements are always welcome. I can help with API specs, if something is missing or not clear.

[InputOutputZ]

Hi all,

I just had chance to make a PR, I think it improves the frontend implementation using Webpack. I didn't see any need for Typescript therefore left it out.
#46

With thanks.

[alsoLut]

i don't think webpack has any usefulness in projects like this

[InputOutputZ]

Hmmm I thought it could be useful down the line when the list of JS scripts grows, difficult to update, maintain and manage alongside styling and gets more complex, difficult to maintain the project otherwise as a result.

Anyhow, I do agree on page routing, I think it would be great if implemented to lighten the load on Rules and Connections view through separation. I think maybe https://vuejs.org/ can help in implementing this, or even something basic perhaps using datatables script, would be good option to implement paginated connections and rules list, and even better for rules entries themselves, 600K+ blocklist entries is too much, and breaks on my phone.

[starkjohann]

Hi, thanks for putting this together! I see you've invested real effort and any contribution is appreciated!

That said: our preference is to keep the frontend build-free, shipping plain readable JS and CSS that's easy to debug at every level. Webpack adds complexity that doesn't feel like the right trade-off for us right now, so I'm not sure we'll be able to merge this one.

For future contributions, it's always worth a quick chat before diving into larger changes — happy to discuss ideas upfront anytime.

BTW: The blocklists are paginated under the hood. The view fetches only the visible rows. Might still be hard to work with a slider on large lists, though, but I would not want to have a page 1 ... page 60,000 pagination either. And I have found that Firefox has a bug with very large lists, there seems to be a coordinate overflow.

Thanks again!

[InputOutputZ]

Hi, thanks for putting this together! I see you've invested real effort and any contribution is appreciated!

That said: our preference is to keep the frontend build-free, shipping plain readable JS and CSS that's easy to debug at every level. Webpack adds complexity that doesn't feel like the right trade-off for us right now, so I'm not sure we'll be able to merge this one.

For future contributions, it's always worth a quick chat before diving into larger changes — happy to discuss ideas upfront anytime.

BTW: The blocklists are paginated under the hood. The view fetches only the visible rows. Might still be hard to work with a slider on large lists, though, but I would not want to have a page 1 ... page 60,000 pagination either. And I have found that Firefox has a bug with very large lists, there seems to be a coordinate overflow.

Thanks again!

No problem at all. I closed the PR now.