Skip to content

Add UI elements and logic to let users sort the presets in the preset view #833

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

Merged
merged 5 commits into from
Jul 6, 2025

Conversation

bman654
Copy link
Contributor

@bman654 bman654 commented Jun 18, 2025

Works similar to the way model sorting works. defaults to the existing sort order (which is something similar to but not always "last modified").



function onPresetSortByChanged(ev) {
localStorage.setItem('preset_list_sort_by', presetSortBy = ev.target.value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's a lot of odd code format choices in here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you provide any specifics on what you find odd about the format?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commented line has snuck an inline value assignment in the middle of another line. There's double-blanklines all around. There's usage of syntax features that the rest of the codebase generally doesn't use, eg const and ===
The most important thing code in a PR needs to be, syntax wise, is similar to the other code around it in the same project. Otherwise it becomes an issue down the road for maintenance.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok I've gone through and cleaned up the spacing, added comments, and (even though it feels really weird) removed the usages of const and === in favor of the looser let and == syntax.

Let me know if it's still out of line with your JS usage preferences.

const reverseElem = document.getElementById("preset_list_sort_reverse");

if (sortByElem !== presetSortByElement) {
presetSortByElement?.removeEventListener("change", onPresetSortByChanged);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whaaaat is going on here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was running into issues with the actual lifetime of the html elements vs when this code executes. Finally wrote it to defensively check the element each time and add/remove listeners as needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just not store it then, and use getRequiredElementById

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but that function will throw if the element does not exist (which it sometimes doesn't when this code runs). Errors about the element not existing is what led me to wrap it in this code.

I guess since you aren't using any specific front end framework I don't have any real understanding of the lifecycle of the UI elements or order of operations so I'm falling back on patterns that I know are robust when coding straight against the DOM.

Your existing code (models for example) also had logic to deal with this problem (code running before elements exist) but it was coupled to re-fetching data from the server. For example, some of the logic about adding event listeners was tied to the value of isRefresh parameter. I don't have enough context about when or why the code was being called with specific values of isRefresh to feel confident I could lift the same logic and apply it to presets (which have some differences in how they are fetched compared to models).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I again say go look at the image history code, which already handles this stuff.

If you make up a whole new way to solve a problem, that means if something bugs... there's now two different implementations that need to be separately looked into and separately fixed. If there's a feature to add, there's two different implementations that need to have that separately added to.

As much as possible, new things should either use, or exactly copy, the logic of pre-existing code. Not because one way is necessarily better than the other, but because it makes long term maintenance a lot easier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've done my best to make it similar to image history. But the lifecycles are different and it can't be the same. Presets get initialized differently than image history and as a result the wiring up of the event listeners just can't be done the same way. Hopefully this is close enough to what you are looking for.

@mcmonkey4eva
Copy link
Member

This is a really odd code approach. Why is it not just identical to image history or model sort code?

@bman654
Copy link
Contributor Author

bman654 commented Jun 26, 2025

This is a really odd code approach. Why is it not just identical to image history or model sort code?

Both Model and Image History use server-side sorting and have an API endpoint dedicated to retrieving them in sorted order.

Presets does not use server-side sorting and also does not have a dedicated endpoint (looks like they come over as part of "UserData").

I'm working with what's available.

@mcmonkey4eva mcmonkey4eva merged commit e9508fb into mcmonkeyprojects:master Jul 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants