add back count display. allow selected items to be sorted to top

[jaredgibb]

No description provided.

[jaredgibb]

greate

[Copilot]

Pull request overview

This PR adds two main features to the input select component: a count display mode for multi-select that shows the number of selected items instead of individual chips, and the ability to sort selected items to the top of the options list.

Changes:

• Added display mode configuration (chips/count) for multi-select with customizable count text template
• Implemented sorting functionality to move selected options to the top of the list
• Added new changeOneItem event triggered when a single item is selected/unselected
• Modified unselect behavior to automatically enable when sortSelectedToTop is active

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
ww-config.js	Added configuration properties for displayMode, displayText, sortSelectedToTop, and changeOneItem event
src/wwElement_Trigger.vue	Implemented conditional rendering for chips vs count display mode with count text templating
src/wwElement_Select.vue	Added emitChangeEvents helper, isSorting flag for click-outside prevention, and oneItemValue parameter for fine-grained event emission
src/wwElement_Search.vue	Added filterOptions function and searchMatches computation for local context exposure
src/wwElement_OptionsList.vue	Implemented sorting logic for selected items, changed ID generation to use content-based stable IDs
src/wwElement_Option.vue	Modified unselect behavior to automatically enable when sortSelectedToTop is active
AI.md	Documented the new changeOneItem event

Comments suppressed due to low confidence (10)

src/wwElement_OptionsList.vue:213

• Using setTimeout to reset isSorting after a fixed delay is fragile and may cause race conditions. If the dropdown closes before the timeout fires, the flag will be reset after the component is no longer mounted, or if sorting happens again within 100ms, the flag might be reset prematurely. Consider resetting the flag synchronously after the sort completes, or use a more deterministic approach like watching for when the computed property finishes evaluating.

                    setTimeout(() => {
                        isSorting.value = false;
                    }, 100);

src/wwElement_OptionsList.vue:242

• The sort operation creates stable IDs based on JSON.stringify(item) which can be expensive for large objects or arrays. Additionally, using JSON.stringify for object identity is problematic because object property order may vary, circular references will throw errors (caught but resulting in fallback), and it doesn't handle functions, undefined, or symbols properly. Consider using a WeakMap or Symbol to create truly unique identifiers for objects.

                    const stableId = `primitive_${JSON.stringify(item)}`;
                    return { value: item, id: stableId };
                } else {
                    // For objects, use existing id or create stable ID based on the object's value
                    const existingId = item.id;
                    if (existingId != null) {
                        return { ...item, id: existingId };
                    }
                    // Create stable ID based on object content to survive re-sorting
                    try {
                        const stableId = `obj_${JSON.stringify(item)}`;
                        return { ...item, id: stableId };

src/wwElement_Trigger.vue:336

• The template.replace method only replaces the first occurrence of '{count}'. If the template string contains multiple instances of '{count}', only the first will be replaced. Use template.replaceAll('{count}', count.toString()) or a global regex replace to handle all occurrences correctly.

            return template.replace('{count}', count.toString());

src/wwElement_Option.vue:285

• Automatically enabling unselectOnClick when sortSelectedToTop is enabled changes user-expected behavior and could be surprising. This implicit coupling means that enabling sorting will also enable unselecting, which may not be desired. Users might want sorted items at the top but still require unselectOnClick to be explicitly false. Consider making this behavior explicit in the documentation or providing a separate configuration option, rather than having one feature implicitly enable another.

            const unselectOnClick = props.content.unselectOnClick ?? false;
            const selectOnClick = props.content.selectOnClick ?? true;
            const sortSelectedToTop = props.content.sortSelectedToTop ?? false;
            
            // Allow unselecting if either:
            // 1. unselectOnClick is explicitly enabled, OR
            // 2. sortSelectedToTop is enabled (natural UX for sorted items)
            const canUnselect = unselectOnClick || sortSelectedToTop;

src/wwElement_OptionsList.vue:173

• The condition checks 'selectedValue.value != null', which will be true even when selectedValue is an empty array [] in multi-select mode. This means sorting logic will run unnecessarily when no items are selected, performing expensive operations for no benefit. Consider checking for 'selectedValue.value?.length > 0' for arrays or a more specific null/undefined/empty check.

            if (props.content.sortSelectedToTop && selectedValue.value != null) {

src/wwElement_Search.vue:101

• The searchMatches computed in the Search component appears to be redundant. The OptionsList component performs its own filtering using memoizedFilter and doesn't use searchMatches for filtering - it only exposes it in the local context for external consumption. Computing searchMatches here duplicates the filtering work that's already happening in OptionsList, adding unnecessary performance overhead. If searchMatches is only needed for the local context, consider computing it in Select.vue where the local context is assembled, or remove it if it's not actually being used.

                // Compute searchMatches here in the Search component
                const searchMatches = value ? filterOptions(options.value, value) : [];
                updateSearch({ value, searchBy, searchMatches });

ww-config.js:1097

• There's a typo in the comment closing tag. It should be "wwEditor:end" not "wwEditor:end ." (with a dot and space before the asterisk).

            /* wwEditor:end .*/

src/wwElement_Search.vue:95

• The filterOptions function in Search component duplicates the exact same filtering logic already implemented in memoizedFilter in OptionsList component. This code duplication violates DRY principle and creates a maintenance burden - any changes to the filtering algorithm need to be made in two places. Consider extracting this logic to a shared utility function or having Search component use the same filtering logic from OptionsList.

        const filterOptions = (options, filterValue) => {
            if (!filterValue) return options;
            
            return options.filter(option => {
                // Handle primitive values directly
                const isPrimitive = typeof option !== 'object' || option === null;
                if (isPrimitive) {
                    const normalizedOption = option
                        .toString()
                        .normalize('NFD')
                        .replace(/[\u0300-\u036f]/g, '')
                        .toLowerCase();
                    const normalizedFilter = filterValue
                        .normalize('NFD')
                        .replace(/[\u0300-\u036f]/g, '')
                        .toLowerCase();
                    return normalizedOption.includes(normalizedFilter);
                } else {
                    // For objects, use the existing search logic
                    const searchByFields = searchState.value?.searchBy?.length
                        ? searchState.value?.searchBy
                        : Object.keys(option);
                    return searchByFields.some(key => {
                        const optionValue = option[key];
                        if (!optionValue) return false;
                        const normalizedOption = optionValue
                            .toString()
                            .normalize('NFD')
                            .replace(/[\u0300-\u036f]/g, '')
                            .toLowerCase();
                        const normalizedFilter = filterValue
                            .normalize('NFD')
                            .replace(/[\u0300-\u036f]/g, '')
                            .toLowerCase();

                        return normalizedOption.includes(normalizedFilter);
                    });
                }
            });
        };

src/wwElement_Trigger.vue:335

• The fallback value 'Selected: {count}' is hardcoded in English. If props.content.displayText is undefined or null (e.g., in an older configuration without this property), the component will always display English text, breaking internationalization for other languages. Consider using a proper i18n key or ensuring the default value from ww-config.js is always present.

            const template = wwLib.wwLang.getText(props.content.displayText) || 'Selected: {count}';

src/wwElement_Search.vue:101

• There's a potential race condition in searchBy usage. filterOptions (line 100) uses searchState.value?.searchBy from the previous updateSearch call, but the new searchBy is passed to updateSearch immediately after (line 101). If searchBy changes between calls, the searchMatches will be computed using the old searchBy but stored with the new searchBy, causing inconsistency. Consider passing searchBy directly to filterOptions instead of relying on searchState.value?.searchBy, or use the searchBy parameter from debouncedUpdateSearch directly in the filtering logic.

        const debouncedUpdateSearch = debounce((value, searchBy) => {
            if (updateSearch) {
                // Compute searchMatches here in the Search component
                const searchMatches = value ? filterOptions(options.value, value) : [];
                updateSearch({ value, searchBy, searchMatches });

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The isSorting flag is being set within a computed property, which violates Vue's reactivity principles. Computed properties should be pure functions without side effects. Setting isSorting.value inside filteredOptions computed will cause it to run during every reactivity cycle, potentially triggering the setTimeout multiple times. This should be moved to a watcher or a method that is called when sorting is actually needed.

[Copilot]

The displayMode check doesn't handle the case where content.displayMode is undefined or null (backward compatibility for older configurations). When displayMode is undefined, the condition 'content.displayMode === "chips"' will be false, and 'content.displayMode === "count"' will also be false, so the component will fall through to showing the placeholder even when options are selected. Consider using 'content.displayMode !== "count"' for the chips condition to maintain backward compatibility with existing components that don't have displayMode set.

Suggested change

	<div v-if="isOptionSelected && content.displayMode === 'chips'" class="ww-input-select__chip_container">
	<div v-if="isOptionSelected && content.displayMode !== 'count'" class="ww-input-select__chip_container">