feat(components): introduce the Select and Listbox components#121
feat(components): introduce the Select and Listbox components#121desmondinho merged 79 commits intomainfrom
Conversation
…xItem components
WalkthroughThe pull request introduces a comprehensive implementation of the Changes
Assessment against linked issues
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
desmondinho
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (89)
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/LabelPlacements.razor (1)
3-3: Consistent snippet naming could improve clarity.Providing a meaningful name for the code snippet can help with maintainability. Consider replacing
nullwith a unique, descriptive name that matches your existing naming conventions.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/_Radius.razor (3)
1-1: Remove BOM character to ensure consistent encoding.It appears there is a byte order mark (BOM)
\uFEFFright at the beginning of the file. While many editors ignore this, it can sometimes cause issues in certain environments or git diffs.
5-15: Consider demonstrating a default selection or placeholder.Users might find it helpful to see how to set a default or placeholder selection (e.g., “Select an animal”). This can clarify usage of the
LumexSelectfor scenarios requiring default states.
22-37: Make the animals dictionary read-only if it never changes.If
_animalsis not updated at runtime, consider making itstatic readonly(orconst Dictionarypattern) to reflect that it’s a fixed set of data. This minor change can help clarify intent and keep the data immutable.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Disabled.razor (1)
6-11: Consider extracting shared data for maintainability.You are rendering a list of animals from the
_animalsdictionary. If these items are used consistently in other files (as the summary suggests), consider centralizing this dictionary in a shared location to avoid duplication.-@foreach (var animal in _animals) -{ - <LumexSelectItem @key="@animal" Value="@animal.Key"> - @animal.Value - </LumexSelectItem> -} +<!-- Potential approach: reference a shared data class or static property -->docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Sizes.razor (1)
3-5: Consider providing a meaningful name instead ofnull.When constructing the
PreviewCodecomponent with@new(name: null, ...), providing a descriptivenamecan improve clarity and maintainability for both contributors and documentation readers.-<PreviewCode Code="@new(name: null, snippet: "Select.Code.Sizes")"> +<PreviewCode Code="@new(name: "Sizes Example", snippet: "Select.Code.Sizes")">src/LumexUI/Components/Listbox/LumexListbox.razor.cs (2)
36-45: Check default color usage
By defaulting theColortoThemeColor.Default(line 44), the styling might blend with other default-themed components. Evaluate if a user might expect a more pronounced visual difference for listboxes.
157-166: Modify item removal logic
InSetSelectedValues(line 160-163), the code toggles the presence of the item in theValuescollection. If removing and adding items in rapid succession is common, consider using a more specialized data structure like a LinkedHashSet or a custom approach to optimize toggling and preserve insertion order if needed.src/LumexUI/Components/Listbox/LumexListboxItem.razor.cs (2)
38-45: Surface clarity forDescription
TheDescriptionparameter (line 44-46) is optional but might confuse accessibility screen readers if used incorrectly. Recommend documenting best practices for usingDescriptionor ensuring alt text for screen readers.
64-68: Disable logic
Disabled(line 67) can be combined withListbox?.DisabledItems, so it works seamlessly. However, ensure that parent-level toggles (e.g., entire listbox disabled) properly override or unify with this item-levelDisabledstate.src/LumexUI/Components/Select/LumexSelect.razor (1)
90-158: Single vs. multiple selection
The code checks_context.IsMultiSelect(line 100-101, 128) and renders different<LumexListbox>usage. This design is consistent. If future expansions add more selection modes (e.g., range selection), consider an extensible approach rather than if/else blocks.src/LumexUI/Components/Select/LumexSelect.razor.cs (3)
16-20: Generic constraints
Declaringpublic partial class LumexSelect<TValue> : LumexInputBase<TValue>, ...is flexible. If you anticipate restrictingTValueto certain types, consider generic constraints (e.g.,where TValue : IComparable) to prevent runtime errors.
42-45: Placeholder usage
Line 48-50 references a placeholder. In multi-select scenarios, placeholders might be overshadowed by existing tags or chips. Consider clarifying how placeholders behave when multiple items are selected or partially selected.
279-283: Check concurrency for multi-select
When handlingOnValuesChangedAsync,_context.UpdateSelectedItems(CurrentValues)is triggered (line 282). If multiple select operations happen rapidly, ensure asynchronous calls toSetCurrentValuesAsyncdo not cause data races.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Usage.razor (1)
1-1: Possible BOM character at file start
Some editors or build pipelines may inadvertently insert a Unicode Byte-Order Mark (BOM) at the beginning of this file. In most cases, it's harmless, but it can cause unexpected behavior in certain scenarios. Consider removing it if it's not required.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Colors.razor (1)
1-1: Check for BOM presence
A Unicode BOM might appear at the beginning of the file. It's often unnecessary and can create encoding issues for certain tooling.docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Usage.razor (1)
1-1: Remove or confirm BOM usage
A possible BOM character detected at the start of the file. While not always harmful, it can lead to unexpected behaviors in specific environments.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Radius.razor (1)
1-1: Potential BOM
You may want to remove the leading BOM if not explicitly required for your encoding needs.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Variants.razor (2)
1-1: Avoid potential byte-order-mark issues.
The file seems to contain a BOM (Byte-Order Mark) at the start. Some editors or build pipelines may have trouble with BOM characters. Consider removing it to ensure consistent behavior.
3-5: Ensure consistent naming for preview code components.
Here,nameis set tonull, while other preview code examples might eventually adopt a distinct name. For improved clarity when referencing or searching for these components, consider providing a more descriptive and consistentnameproperty or removing it entirely if unneeded.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Required.razor (1)
1-1: Remove or confirm the BOM.
Similar to the previous file, confirm that the leading BOM is intentional. Removing it can help avoid issues with certain build tools or editors.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ReadOnly.razor (1)
1-1: Confirm the presence of BOM.
A BOM at the start can be unintentionally introduced by some IDEs or editors. Verify whether it is required by your project guidelines.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Disabled.razor (1)
1-1: Remove or confirm the BOM.
Ensure the leading BOM character is removed if not explicitly needed.docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Disabled.razor (1)
1-1: Consider providing an SSR fallback.The
@rendermode InteractiveWebAssemblydirective is appropriate for Blazor WebAssembly apps, but for broader compatibility, consider providing a server-side fallback or a hybrid approach if SSR or pre-rendering is needed.docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Description.razor (1)
1-1: Review rendering mode consistency.Reconfirm whether all Listbox preview pages should consistently use
@rendermode InteractiveWebAssembly. If the docs site is hybrid or SSR-based, consider a fallback approach.docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/EmptyContent.razor (2)
2-2: Generic type usage forLumexListbox.
SpecifyingTValue="string"is straightforward for simple scenarios. If you foresee more complex item structures, consider making a dedicated data model.
3-5: Appropriate use ofEmptyContent.
This placeholder content effectively communicates an empty state. The whimsical(o_o)/also adds a bit of personality. Just confirm that escaping the parentheses is desired.docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomStyles.razor (1)
8-14: Reuse style logic across samples if appropriate.If the
_classesobject is used in multiple examples, consider encapsulating this styling logic to promote consistency.docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingSingle.razor (1)
1-13: Consider providing a default or placeholder state for clarity.
Currently, the listbox displays items immediately with "cat" selected. For a clearer user experience, you might consider adding a default or placeholder option that indicates "Select an animal..." or similarly clarifies the initial state.docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingMultiple.razor (1)
15-17: Initialize a more descriptive default set.
Currently, the selection defaults to just ["cat"]. Consider initializing multiple items or adding a comment explaining why "cat" alone is pre-selected, improving clarity for readers.src/LumexUI/Components/Listbox/ListboxSlots.cs (1)
1-28: Design looks flexible; consider future extensibility.
The slots (Root,List,EmptyContent) cover fundamental style overrides. If future components need further slot customizations (e.g., a "Footer" slot), building in extension points now may be beneficial.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Required.razor (1)
1-12: Consider externalizing the dictionary or using a shared service for the animal list.While this example is fine for demonstration, constants like
_animalsrepeated across multiple examples can become harder to maintain. A shared service or a dedicated constants file could reduce duplication and ease updates.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ReadOnly.razor (1)
1-12: Prevent user confusion with read-only elements.When using
ReadOnly="@true", consider providing a visual indication (e.g., a label or tooltip) so users understand why they cannot change the selection. This helps improve accessibility and user experience.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/DisabledItems.razor (1)
14-29: Reduce repetitive dictionary definitions across files.As with similar examples, centralizing the
_animalsdictionary could avoid duplication. This helps ensure future updates to the animal list are reflected consistently across all component examples.src/LumexUI/Components/Listbox/ListboxContext.cs (3)
5-6: Prefer explicit constructor syntax for clarity and compatibility.While C# 11 parameterized constructors in class declarations can improve conciseness, some tooling or older compilers may not fully support them. If your project targets older environments or tools that do not support this syntax, consider switching to an explicit constructor format for broader compatibility.
-internal class ListboxContext<TValue>( LumexListbox<TValue> owner ) : IComponentContext<LumexListbox<TValue>> +internal class ListboxContext<TValue> : IComponentContext<LumexListbox<TValue>> +{ + public ListboxContext(LumexListbox<TValue> owner) + { + Owner = owner; + } + + ... +}
13-19: Conditional check is correct, but consider logging or warnings upon ignored calls.When
_collectingItemsis false, any attempt to register an item is silently ignored. Consider logging or throwing if this indicates a potential misconfiguration or a usage error.
26-35: Confirm the necessity ofStartCollectingItemsandFinishCollectingItems.This two-phase approach is beneficial if the listbox has a definite update window. Verify that the rest of the lifecycle code truly depends on this approach, or consider a more continuous update strategy to simplify usage.
docs/LumexUI.Docs.Client/Components/NavItemBadge.razor (1)
25-29: Consider default or fallback for non-mapped statuses.If new statuses are added to
ComponentStatusbut not to_variants, index access could fail. Consider usingTryGetValuewith a fallback style or logging.+_variants.TryGetValue(Status.Value, out var classes) + ? classes + : "bg-gray-100 ring-gray-300 text-gray-600",docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Description.razor (1)
1-12: Provide a fallback in case_animalsis empty or null.Currently, the loop renders nothing if
_animalsis empty. Consider handling this with a placeholder item or a message, improving the user experience if data is missing.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Usage.razor (2)
1-11: Consider providing a default placeholder for the first select.
While the first select works, providing a placeholder in both selects makes the UI more consistent and user-friendly.
26-42: Ensure dictionary is updated or retrieved dynamically if needed.
Storing these items in a static dictionary is fine for demo purposes, but in production scenarios, consider loading data dynamically from a service or configuration to keep the component flexible.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ErrorMessage.razor (1)
19-34: Potential duplication of animal catalogs.
It seems multiple examples define their own_animalsdictionary. Consider sharing resources or using a single data store to avoid repetition.src/LumexUI/Components/Listbox/LumexListbox.razor (1)
17-23: Consider additional accessibility attributes for the container.
Currently, there's no mention of ARIA attributes or roles in the<div>or nested components. Listbox functionalities often benefit from attributes likerole="listbox", especially for assistive technology.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/StartEndContent.razor (1)
19-25: Avoid reusing the same_animalsin more advanced scenarios.
If you incorporate additional logic around_animals(e.g., advanced searching, categorization, or localization), consider refactoring it into a shared model or service.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Colors.razor (2)
2-19: Concise approach for iterating_colors.
This section effectively demonstrates the differentThemeColoroptions with a single snippet of code. Ensure each color aligns well with the design guidelines.
22-38: Straightforward dictionary for animals.
Checking if there's any overlap with the dictionary inStartEndContent.razor. Consider consolidating repeated dictionaries if needed.src/LumexUI/Components/Select/Core/_ItemsCollectedNotifier.cs (1)
28-31: Attach method override is acceptable.
Though empty, consider adding a short comment explaining the rationale for an empty implementation to inform future maintainers.public void Attach(RenderHandle renderHandle) { - // This component never renders, so we can ignore the renderHandle + // This component never renders UI elements. We override Attach to fulfill the IComponent contract. }docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Sizes.razor (1)
36-53: Animal dictionary usage is straightforward.
Storing options in a dictionary is an effective design choice, though consider centralizing it in a shared file if used across multiple examples.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Variants.razor (1)
36-53: Dictionary approach parallels the previous file.
As with the Sizes example, centralizing the_animalsdictionary may improve maintainability, but this is non-blocking.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/LabelPlacements.razor (2)
2-3: Consider filtering specific label placements if needed.
Right now,Enum.GetValues<LabelPlacement>()iterates over every enum option. If certain options are irrelevant or experimental, it might be helpful to limit or filter them for clarity in the documentation examples.
6-16: Ensure consistent styling or add clarifying notes for the first<LumexSelect>.
While the usage is straightforward, consider adding a short note or region callout explaining the differences between label vs. placeholder usage, especially for first-time readers browsing the documentation example.src/LumexUI/Components/Select/LumexSelectItem.cs (1)
37-41: Validation is effective but consider supporting default values.
Currently, an exception is thrown ifValueis null. In some edge cases, it might be desirable to have a null-safe fallback or an appropriate default to allow partial initialization.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingSingle.razor (2)
20-25: Keep binding style consistent.
Here, you explicitly bind withValueandValueChanged, whereas above you used@bind-Value. Both approaches are correct, but pick one for consistency across this documentation page.
57-58: Clear naming for your fields.
Renaming_valueOneand_valueTwoto something more descriptive (e.g.,_selectedAnimalOne,_selectedAnimalTwo) can improve clarity in this documentation snippet.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingMultiple.razor (2)
24-25: Add a quick explanation ofValuesvs.ValuesChangedusage.
In documentation examples, providing a brief comment about the mechanism behind these parameters can clarify the difference from single-value binding.
57-58: Consider using a strongly typed list.
Instead ofICollection<string>?, you may want to use a more specific type (e.g.,List<string>?) if the order matters or if you want certainList<T>behaviors in your code sample.src/LumexUI/Components/Listbox/LumexListboxItem.razor (3)
1-3: Consider adding a documentation comment for the type parameter.
Adding a short summary of the generic parameter’s role can improve clarity for anyone extending or using this component.
15-48: Improve accessibility with attributes.
You might consider addingaria-selected,aria-disabled, and relevant ARIA roles (e.g.,option) to enhance screen-reader support, especially given that this is a selectable item in a listbox.
50-67: Consider providing an accessible name for the selected icon.
Including anaria-labelortitleattribute in the<svg>can help screen readers convey the meaning of the selection icon to visually impaired users.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomItems.razor (2)
5-20: Validate large data sets.
If you anticipate large lists, you might want to showcase or document virtualization or lazy-loading best practices in the future.
24-40: Consider demonstrating advanced usage.
YourCharacterrecord is sufficient for this example, but consider adding a note on filtering or searching for a more robust illustration.docs/LumexUI.Docs.Client/Components/NavMenu.razor (1)
53-53: Add user feedback when items are disabled.
Adding a tooltip or label (e.g., “Coming Soon”) can give context on why the item is disabled instead of just removing pointer events.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomValues.razor (3)
1-5: Use consistent labeling or placeholders to avoid user confusion.
While theLabel="Assign To"andPlaceholder="Select a character"are clear, ensure that they harmonize with other select components in the docs for a uniform user experience. For instance, consistently using "Select a [subject]" across multiple examples helps users quickly recognize and use the component.
7-20: Consider extracting_characterlogic or item rendering into reusable partials or methods.
You may improve maintainability by moving theforeachloop or item layout into a dedicated reusable method or partial. This ensures consistency and makes the code more scalable for future expansions (e.g., adding filtering, sorting, or dynamic data sources).
36-51: Verify large data sets or potential performance pitfalls.
The_characterarray is currently small, but ensure that if the data grows significantly, performance remains acceptable. In high-volume contexts, consider virtualization or efficient state updates.docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/CustomStyles.razor (5)
3-6: Ensure consistent theming for default vs. flat variants.
TheVariant="@ListboxVariant.Flat"might need consistent theming across other components for a smooth look-and-feel, especially if you use different variants in the doc examples.
7-55: Offer item grouping or categorization if the list grows.
Currently, each<LumexListboxItem>references a single data entry with start and end content. If you plan to show extended lists (e.g., more categories or sub-items in the future), consider grouping or chunking them for better UX.
58-62: Consider a more descriptive name for_iconWrapper.
_iconWrapperis clear enough, but naming it something likeBuildIconWrapperorRenderIconWrappermight improve clarity, especially if more wrapper methods are introduced later.
67-71: Adjust the sizing or spacing for counters.
You might want to tweak the line-height or vertical alignment for the text inside_counterto ensure it aligns neatly with icons and the rest of the list item.
73-82: Customize or unify style definitions.
Duplicates could arise if you define similar styles for multiple listboxes. Consider unifying them in a shared style or config to keep the styles consistent across docs.docs/LumexUI.Docs.Client/Common/Navigation/NavigationStore.cs (2)
35-35: Document the difference betweenComponentStatus.NewandComponentStatus.Preview.
Adding theLumexListbox<T>as a "New" component is clear, but note in your docs that "Preview" typically indicates a pre-release or feature-in-progress. This distinction helps users know how stable or experimental the component is.
39-39: Maintain alphabetical or logical ordering.
If you keep a specific order (alphabetical or by release date), ensure that newly added items are consistently placed. It avoids confusion when scanning through a large set of components.docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomStyles.razor (5)
7-21: Consider a grouping or search approach for large character sets.
The code simply loops over_character. If the number of entries grows, a grouping or search feature might enhance usability.
37-51: Enable dynamic data loading if needed.
The_characterarray is statically defined, which is fine for demos. For real-world scenarios, consider hooking into an async service for dynamic data.
53-65: Ensure consistent theming or unify style references.
Your_selectClassesdefine custom spacing and styling. If you have multiple instances ofLumexSelectthroughout the docs, reusing or referencing shared style definitions can unify the doc’s appearance.
67-76: Refine hover behavior for items.
You’re adding transitions and hover states in_selectItemClasses. Consider consistent timing or ease curves to match your typical transitions across the library.
88-88: Consider making theCharacterrecord public or in a shared location.
If used across multiple components or features, placingCharacterin a shared namespace can avoid duplication.src/LumexUI/Components/Popover/LumexPopover.razor.cs (3)
24-28: Enforce clearer documentation for 'Id' parameter.
WhileIdis self-explanatory, adding a brief description in the<summary>tag about its usage and implications (e.g., referencing) will improve overall clarity.
92-96: InvokeOpenedChangedunder all conditions.
Double-check thatOpenedChangedis raised in every scenario that toggles theOpenedproperty, including corner cases such as popover cancellation or forced closing.
134-136: Potential concurrency risk when multiple popovers are triggered simultaneously.
If multiple popovers can be triggered at once, verify that there's no race condition setting a different popover as the last shown.docs/LumexUI.Docs.Client/Pages/Components/Listbox/Listbox.razor (4)
1-3: Document route and layout usage.
The top lines define the route (@page "/docs/components/listbox") and layout (DocsContentLayout), but there’s no explicit mention of them in the page’s explanatory text. Consider adding a short note in the introduction for clarity.
8-30: Prevent duplication by consolidating usage details.
The sub-sections under Usage (Disabled, DisabledItems, etc.) are well structured. However, repeating similar text about disabling items might confuse end users. Check if merging or cross-referencing the two approaches would simplify the documentation.
64-83: Encourage clarity on single vs multiple selection states.
Two-way data binding can differ significantly for single vs multiple selections. Consider highlighting potential pitfalls (like ensuring unique item values) for multi-select scenarios.
86-123: Explain deeper how to leverage 'data-*' attributes.
Listing the named slots is helpful, but a small usage snippet illustrating how to style them via[data-root="..."]or[data-list="..."]might guide users who are new to custom CSS.docs/LumexUI.Docs.Client/Pages/Components/Select/Select.razor (4)
1-3: Provide a short note on the purpose of the Select component.
Although these lines define the route and layout, consider adding a quick overview of the Select component’s usage in the doc’s introduction.
15-28: Clarify distinction between selecting disabled items vs disabling the entire select.
The doc outlines disabling the entire select or specific items. Some readers might be unsure if the latter approach overrides the former. A short note clarifying the interplay could prevent confusion.
43-51: Elaborate on size vs design consistency.
TheSizesandRadiussections are separate, but frequently used together. Consider referencing the other section to guide users to consistent design decisions.
101-120: Two-way data binding examples.
The examples (TwoWayDataBindingSingleandTwoWayDataBindingMultiple) are helpful. Suggest adding a note on how these behave in an MVVM or state management scenario for advanced usage.src/LumexUI/Common/Enums/ListboxVariant.cs (1)
7-18: Add XML comment for publicly visible enum 'ListboxVariant'.
Static analysis highlights a missing XML comment. A succinct<summary>helps clarify each variant’s purpose.+ /// <summary> + /// Specifies style variants for the LumexListbox component. + /// </summary> public enum ListboxVariant { Solid, ... }🧰 Tools
🪛 GitHub Check: build-test
[warning] 7-7:
Missing XML comment for publicly visible type or member 'ListboxVariant'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (82)
docs/LumexUI.Docs.Client/Common/Enums/ComponentStatus.cs(1 hunks)docs/LumexUI.Docs.Client/Common/Navigation/NavigationStore.cs(3 hunks)docs/LumexUI.Docs.Client/Common/Navigation/Types.cs(1 hunks)docs/LumexUI.Docs.Client/Components/NavItemBadge.razor(2 hunks)docs/LumexUI.Docs.Client/Components/NavMenu.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/ColorsVariants.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/CustomStyles.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Description.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Disabled.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/DisabledItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/EmptyContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/StartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingMultiple.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingSingle.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Usage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/Listbox.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/ColorsVariants.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/CustomStyles.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Description.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Disabled.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/DisabledItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/EmptyContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/StartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/TwoWayDataBindingMultiple.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/TwoWayDataBindingSingle.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Usage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Colors.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomStyles.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomValues.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Description.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Disabled.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/DisabledItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ErrorMessage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ItemStartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/LabelPlacements.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ReadOnly.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Required.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Sizes.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/StartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingMultiple.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingSingle.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Usage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Variants.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/_Radius.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Colors.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomStyles.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomValues.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Description.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Disabled.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/DisabledItems.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ErrorMessage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ItemStartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/LabelPlacements.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Radius.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ReadOnly.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Required.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Sizes.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/StartEndContent.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/TwoWayDataBindingMultiple.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/TwoWayDataBindingSingle.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Usage.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Variants.razor(1 hunks)docs/LumexUI.Docs.Client/Pages/Components/Select/Select.razor(1 hunks)src/LumexUI/Common/Enums/ListboxVariant.cs(1 hunks)src/LumexUI/Components/Bases/LumexInputBase.cs(2 hunks)src/LumexUI/Components/Listbox/ListboxContext.cs(1 hunks)src/LumexUI/Components/Listbox/ListboxItemSlots.cs(1 hunks)src/LumexUI/Components/Listbox/ListboxSlots.cs(1 hunks)src/LumexUI/Components/Listbox/LumexListbox.razor(1 hunks)src/LumexUI/Components/Listbox/LumexListbox.razor.cs(1 hunks)src/LumexUI/Components/Listbox/LumexListboxItem.razor(1 hunks)src/LumexUI/Components/Listbox/LumexListboxItem.razor.cs(1 hunks)src/LumexUI/Components/Popover/LumexPopover.razor.cs(4 hunks)src/LumexUI/Components/Popover/LumexPopoverContent.razor(1 hunks)src/LumexUI/Components/Popover/LumexPopoverContent.razor.cs(1 hunks)src/LumexUI/Components/Popover/PopoverContext.cs(1 hunks)src/LumexUI/Components/Select/Core/_ItemsCollectedNotifier.cs(1 hunks)src/LumexUI/Components/Select/LumexSelect.razor(1 hunks)src/LumexUI/Components/Select/LumexSelect.razor.cs(1 hunks)src/LumexUI/Components/Select/LumexSelectItem.cs(1 hunks)
⛔ Files not processed due to max files limit (14)
- src/LumexUI/Components/Select/SelectContext.cs
- src/LumexUI/Components/Select/SelectSlots.cs
- src/LumexUI/Scripts/Plugin/plugin.js
- src/LumexUI/Scripts/Plugin/scrollbar-hide.js
- src/LumexUI/Scripts/Plugin/transitions.js
- src/LumexUI/Styles/ColorVariants.cs
- src/LumexUI/Styles/Listbox.cs
- src/LumexUI/Styles/Select.cs
- src/LumexUI/_Imports.razor
- src/LumexUI/wwwroot/js/components/popover.bundle.js
- src/LumexUI/wwwroot/js/components/popover.js
- tests/LumexUI.Tests/Components/Listbox/ListboxTests.razor
- tests/LumexUI.Tests/Components/Popover/PopoverTests.razor
- tests/LumexUI.Tests/Components/Select/SelectTests.razor
✅ Files skipped from review due to trivial changes (3)
- docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Usage.razor
- docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/TwoWayDataBindingSingle.razor
- docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Description.razor
🧰 Additional context used
🪛 GitHub Check: build-test
src/LumexUI/Common/Enums/ListboxVariant.cs
[warning] 7-7:
Missing XML comment for publicly visible type or member 'ListboxVariant'
🔇 Additional comments (134)
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/DisabledItems.razor (1)
1-1: Looks good for enabling client-side interaction.
Using @rendermode InteractiveWebAssembly is appropriate for demonstrating interactive Blazor components in the docs.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/LabelPlacements.razor (2)
1-1: Confirm .NET version compatibility.
@rendermode InteractiveWebAssembly is introduced in newer .NET releases. Ensure the project targets the appropriate .NET version and that no fallback or polyfill is required for older environments.
4-5: Looks good!
Supplementing <LumexUI.Docs.Client.Pages.Components.Select.Examples.LabelPlacements /> with additional descriptive text or commentary may help readers understand the example’s purpose.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Disabled.razor (2)
1-5: Ensure the label is accessible to assistive technologies.
While using <LumexSelect> with a Label attribute typically improves accessibility, it's good practice to verify that this label is correctly associated with the underlying input element for screen readers.
14-30: Dictionary is well-structured for demonstration scenarios.
Storing the data in a private dictionary is perfectly valid for example documentation. Ensure that, in production code, you handle large data sets or dynamic data with caution, potentially using a dedicated data service or a more robust approach.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Sizes.razor (1)
1-1: Ensure compatibility of the @rendermode InteractiveWebAssembly.
Confirm that your project configuration and hosting environment support this rendering mode. While it's a powerful feature for Blazor WebAssembly projects, it may require additional setup or usage instructions.
src/LumexUI/Components/Bases/LumexInputBase.cs (2)
180-180: Consider ensuring consistent validation messaging when parsing succeeds.
The assignment to CurrentValue and subsequent call to SetValidationMessageAsync nicely handles the scenario where parsing is successful. As a precaution, ensure that if multiple rapid updates occur, the final user-facing validation state remains accurate and that derived classes aren’t unintentionally overridden in asynchronous flows.
224-230: Providing a default no-op implementation is a good improvement.
Changing SetValidationMessageAsync from an abstract to a virtual method reduces boilerplate in derived classes that do not require special validation logic. Just ensure that any existing overrides remain functional if they rely on previously enforced contract constraints.
src/LumexUI/Components/Listbox/LumexListbox.razor.cs (4)
13-17: Ensure consistent namespace documentation
The XML summary references <see cref="LumexListbox{T}"/> in line 17, but this file defines LumexListbox<TValue>. Although functionally correct, confirm that the references match any final naming or usage patterns for documentation.
113-120: Conflicting parameters
The code correctly throws an exception if both Value and Values are specified, preventing ambiguous states (line 118-119). No changes needed, but ensure end-user documentation is updated accordingly.
150-155: Validate the single selection update
When calling SetSelectedValue, the logic sets Value and invokes ValueChanged. Confirm any subsequent state updates, especially in parent components, handle the new Value synchronously to avoid stale references.
168-171: Memoized style retrieval
GetSlots fetches styles by delegating to Listbox.GetStyles. The usage of _slotsMemoizer ensures performance optimization by preventing unnecessary re-calculations. Looks good.
src/LumexUI/Components/Listbox/LumexListboxItem.razor.cs (3)
16-21: Confirm the [CompositionComponent] usage
The attribute [CompositionComponent(typeof(LumexListbox<>))] is an interesting choice. Verify that this composition pattern doesn’t conflict with the existing Blazor lifecycle and any parent-child relationship constraints.
146-159: Event callbacks in OnClickAsync
The code checks GetDisabledState() and returns early (lines 148-151). Then selection is handled, followed by the OnClick callback. Consider capturing any exceptions inside await OnClick.InvokeAsync to avoid swallowing errors from user code.
183-186: Ensure unregistration from context
The Dispose method (line 183-186) properly calls Context?.Unregister(this). Verify that removing many items and re-rendering them rapidly will not cause concurrency issues or leftover references in the Context.
src/LumexUI/Components/Select/LumexSelect.razor (2)
5-9: Defer usage
The code defers the final rendering until _context.FinishCollectingItems() is called (line 14). This approach is beneficial, but be sure to handle race conditions if user interactions occur before the Defer block completes.
31-43: Conditional label rendering
You conditionally render _renderLabel inside or outside the trigger (line 31 vs line 42). This pattern offers flexibility in UI layout. Confirm the user can easily configure LabelPlacement from the parent if needed.
src/LumexUI/Components/Select/LumexSelect.razor.cs (3)
198-203: Parameter conflict
The code throws an exception if both Value and Values are specified (line 201-203). This is consistent with the listbox approach. Request verifying that any custom typed parameters (Nullable<TValue> vs. TValue) do not inadvertently bypass this check in advanced usage.
252-258: TryParseValueFromString override
You return false unconditionally, presumably because your select handles typed values differently. Ensure you document that textual input binding is unsupported. This approach is fine as is.
270-277: Synchronization with parent
OnValueChangedAsync sets the current value prop, then hides the popover, and calls _context.UpdateSelectedItem(CurrentValue). Confirm that any parent components are also updated (e.g., StateHasChanged() if needed in advanced scenarios).
docs/LumexUI.Docs.Client/Common/Enums/ComponentStatus.cs (1)
3-6: Enum expansion
Adding New (line 5) to ComponentStatus is straightforward. Approve the clarity, but ensure backward compatibility if any code previously mapped numeric values in the older enum.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Usage.razor (1)
3-5: Double-check snippet existence
Confirm that the snippet "Listbox.Code.Usage" exists and is properly linked in the project.
✅ Verification successful
The snippet will be auto-generated from the example
Based on the codebase analysis, I can see that the system is designed to automatically generate code snippets from example files. The CodeSnippets.cs contains logic that:
- Looks for Razor files in the
Examplesdirectory - Converts them to HTML/markdown format
- Saves them in a corresponding
Codedirectory
The example file exists at docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Usage.razor, and the system will automatically generate the corresponding code snippet. The PreviewCode component is correctly configured to reference this auto-generated snippet.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching for 'Listbox.Code.Usage' occurrences in the repo
rg "Listbox.Code.Usage"
Length of output: 167
Script:
#!/bin/bash
# Search for files containing 'Listbox' and 'Code' in their path or content
fd -t f -e cs -e razor "Listbox|Code" --exec rg -l "Code|Listbox"
# Search for any code snippets or resource files that might contain the snippet
fd -t f "Listbox" --exec rg -l "Usage"
Length of output: 1015
Script:
#!/bin/bash
# Check the content of CodeSnippets.cs to verify if the snippet is defined
cat ./docs/LumexUI.Docs.Generator/CodeSnippets.cs
# Check the content of the Usage example
cat ./docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Usage.razor
Length of output: 3887
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Radius.razor (1)
3-5: Validate code snippet reference
Ensure "Select.Code._Radius" references a valid snippet in the code or documentation.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Required.razor (1)
3-5: Check snippet naming consistency.
The snippet: "Select.Code.Required" string is consistent with the file name. If you plan to unify snippet names across multiple preview code files, make sure to follow a consistent pattern (e.g., "Select.Code.ReadOnly" in ReadOnly.razor, "Select.Code.Variants" in Variants.razor).
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ReadOnly.razor (1)
3-5: Validate snippet usage.
For consistency, verify that the snippet "Select.Code.ReadOnly" matches the actual code listing in your documentation. If you find it beneficial, rename or reorganize the snippet for clarity.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Disabled.razor (1)
3-5: Consistent snippet key usage.
Double-check that "Select.Code.Disabled" accurately reflects your naming conventions and is documented in your code samples or snippet listings.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Disabled.razor (1)
3-5: Check snippet reference for completeness.
Ensure that "Listbox.Code.Disabled" snippet is correctly defined and accessible. This helps prevent broken links in the documentation.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomItems.razor (2)
1-1: Use a consistent rendering mode strategy across all previews.
If you are using @rendermode InteractiveWebAssembly for multiple documentation components, validate they all share consistent rendering strategies to maintain a uniform user experience throughout your docs site.
3-5: Verify snippet reference for custom items.
Validate that "Select.Code.CustomItems" points to the correct snippet so that users can properly see the associated code example.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ErrorMessage.razor (2)
1-1: Interactive mode confirmation.
Confirm that @rendermode InteractiveWebAssembly is intended for demos that rely on client-side interactions. Otherwise, consider providing a fallback for broader compatibility.
3-5: Check documentation snippet accuracy.
Ensure that "Select.Code.ErrorMessage" snippet accurately reflects the usage of <LumexUI.Docs.Client.Pages.Components.Select.Examples.ErrorMessage />. Incomplete or outdated snippets can confuse users.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/Description.razor (1)
3-5: Validate "Listbox.Code.Description" snippet integrity.
Double-check that the snippet reference is active and matches the example’s contents. This ensures readers see the correct code details in your documentation.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomValues.razor (2)
1-1: Rendering mode usage confirmed.
Using @rendermode InteractiveWebAssembly here looks correct for enabling interactive Blazor WebAssembly functionality.
3-5: Verify snippet reference.
Ensure that "Select.Code.CustomValues" is properly defined and accessible within the documentation codebase.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/CustomStyles.razor (2)
1-1: Rendering mode usage confirmed.
@rendermode InteractiveWebAssembly is consistent with the approach used in other Blazor WebAssembly documentation pages.
3-5: Verify snippet reference for custom styles.
Double-check that the snippet "Listbox.Code.CustomStyles" is defined and referenced correctly in the documentation codebase, ensuring consistency across your docs.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/EmptyContent.razor (2)
1-1: Rendering mode usage confirmed.
Using Blazor WebAssembly rendering mode here aligns with your interactive doc previews.
3-5: Verify snippet reference for empty content.
Confirm that the snippet "Listbox.Code.EmptyContent" is defined and that any related code examples match this reference.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/DisabledItems.razor (2)
1-1: Rendering mode usage confirmed.
@rendermode InteractiveWebAssembly is correctly placed for enabling interactive Blazor WebAssembly behavior.
3-5: Verify snippet reference for disabled items.
Check that "Listbox.Code.DisabledItems" is properly declared and accessible, ensuring documentation continuity.
✅ Verification successful
Let me gather more information to verify the snippet reference.
Let me try a different approach to locate the snippet definitions.
Let me check the actual implementation of the DisabledItems example.
The snippet reference "Listbox.Code.DisabledItems" is properly configured and matches the implementation
The verification shows that:
- The snippet reference "Listbox.Code.DisabledItems" is used consistently in the PreviewCodes component
- The corresponding implementation exists at
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/DisabledItems.razor - The example demonstrates a listbox with disabled items functionality, properly showcasing the feature in the documentation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify snippet references for "Listbox.Code.DisabledItems".
rg --context 5 'Listbox\.Code\.DisabledItems'
Length of output: 666
Script:
#!/bin/bash
# Search for snippet definition files related to Listbox
fd -e cs -e razor "Listbox.*Code.*" -x cat {}
Length of output: 49
Script:
#!/bin/bash
# Search for any files containing Listbox code snippets or definitions
rg -g '*.{cs,razor}' -l "Listbox\.Code\." | xargs cat 2>/dev/null
# Also check the Examples directory structure
fd "DisabledItems" --type f
Length of output: 2801
Script:
#!/bin/bash
# Check the DisabledItems example implementation
cat "docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/DisabledItems.razor"
Length of output: 681
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/ColorsVariants.razor (2)
1-1: Ensure environment compatibility with @rendermode directive.
The new @rendermode InteractiveWebAssembly directive requires Blazor on .NET 8 or a compatible version. Confirm that the project's target framework supports this feature.
3-4: Validate snippet reference usage.
The Snippet property is set to "Listbox.Code.ColorsVariants". Ensure that the snippet identifier is defined in your documentation or snippet lookup to avoid runtime errors. Also, verify that <LumexUI.Docs.Client.Pages.Components.Listbox.Examples.ColorsVariants /> is the correct example component for this snippet.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/StartEndContent.razor (2)
1-1: Confirm .NET version for @rendermode InteractiveWebAssembly.
Make sure your project references a Blazor version that supports the @rendermode InteractiveWebAssembly directive. Otherwise, this directive may be ignored or cause build issues.
3-4: Check snippet alignment with example component.
The snippet identifier "Select.Code.StartEndContent" should be properly defined in the snippet codebase/documentation. Verify that <LumexUI.Docs.Client.Pages.Components.Select.Examples.StartEndContent /> is the intended demonstration for this snippet.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/StartEndContent.razor (2)
1-1: Validate Blazor rendering mode.
This directive is a more advanced feature in Blazor. Ensure the documentation site is configured for the correct runtime and that you’ve tested the interactive features in your environment.
3-4: Snippet and component cross-reference.
The snippet key "Listbox.Code.StartEndContent" must match an existing snippet definition. Confirm <LumexUI.Docs.Client.Pages.Components.Listbox.Examples.StartEndContent /> references the correct example, ensuring no mismatch in naming or expected content.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/ItemStartEndContent.razor (2)
1-1: Ensure correct Blazor version for @rendermode InteractiveWebAssembly.
As with the other files, confirm that .NET 8 or compatible Blazor versions are in use. Otherwise, this directive might fallback to a different rendering mode or cause errors.
3-4: Snippet integrity check.
You’re referencing "Select.Code.ItemStartEndContent" for the snippet. Confirm that the corresponding snippet is properly defined and that <LumexUI.Docs.Client.Pages.Components.Select.Examples.ItemStartEndContent /> is indeed the correct example component for demonstrating start/end content in a select item.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/TwoWayDataBindingSingle.razor (2)
3-5: Code snippet referencing appears correct.
The snippet reference "Listbox.Code.TwoWayDataBindingSingle" aligns well with the naming convention. Ensure that the corresponding snippet file and TwoWayDataBindingSingle example are properly placed and compiled without error.
1-1: Review the rendering mode usage.
The @rendermode InteractiveWebAssembly directive is typically used to ensure client-side interactive rendering. Verify that your project and hosting model indeed require this setting, otherwise consider removing or adjusting it.
✅ Verification successful
Based on the search results, I can see that the @rendermode InteractiveWebAssembly directive is consistently used across all preview code files and documentation components in the LumexUI.Docs.Client project. This is a standard pattern in the codebase for components that require client-side interactivity, particularly in documentation and example scenarios.
The rendering mode usage is appropriate and consistent with the project's architecture.
The InteractiveWebAssembly render mode is correctly used here as this is a documentation/preview component that needs to be interactive on the client side. This is evidenced by:
- Consistent usage across all preview code files in the docs project
- Usage in interactive components like PreviewCode, ColorSwatches, and other demo components
- The component's location in the LumexUI.Docs.Client project, which is a WebAssembly-based documentation site
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Checks whether there's any existing usage of this directive for consistency.
rg -A 2 "@rendermode"
Length of output: 63902
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/TwoWayDataBindingMultiple.razor (2)
3-5: Two-way data binding snippet integration.
The snippet "Select.Code.TwoWayDataBindingMultiple" and example component TwoWayDataBindingMultiple are consistent. Confirm the snippet content matches the example's actual usage.
1-1: Confirm your rendering mode preference.
Just like the Listbox usage, ensure you intend to use @rendermode InteractiveWebAssembly. If you plan to leverage Blazor Server or another mode, adjust accordingly.
✅ Verification successful
The InteractiveWebAssembly render mode is consistently used across all Select component examples
The verification shows that @rendermode InteractiveWebAssembly is uniformly applied across all Select component preview code files in the documentation, indicating a deliberate and consistent choice. This includes:
- All variant examples
- Usage demonstrations
- Two-way data binding examples (both single and multiple)
- Various feature demonstrations (sizes, colors, custom styles, etc.)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Searching references to ensure uniform usage of InteractiveWebAssembly within the Select components.
rg -A 2 "@rendermode InteractiveWebAssembly" docs/LumexUI.Docs.Client/Pages/Components/Select
Length of output: 6851
docs/LumexUI.Docs.Client/Pages/Components/Listbox/PreviewCodes/TwoWayDataBindingMultiple.razor (2)
1-1: Check consistency in your rendering mode directives.
All new preview Razor files seem to be using @rendermode InteractiveWebAssembly—this is good for consistency across your documentation samples.
3-5: Snippet and example coherence.
Using "Listbox.Code.TwoWayDataBindingMultiple" as the snippet and including the TwoWayDataBindingMultiple example is coherent. Validate that the snippet name aligns with the actual file references.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/EmptyContent.razor (1)
1-1: Container styling is clear.
The applied utility classes (w-full max-w-60 px-1 py-2) give a concise style. Ensure consistency with other components for uniform design.
src/LumexUI/Components/Popover/PopoverContext.cs (1)
13-13: Consider null-safety on the OnTrigger invocation.
Currently, OnTrigger is initialized to default! and invoked directly without a null check. This may cause a NullReferenceException if no subscriber is assigned. Consider adding a null check or providing a fallback to ensure safe invocation in all scenarios.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/CustomStyles.razor (2)
1-1: Confirm that @rendermode InteractiveWebAssembly is fully supported in your environment.
This directive is typically used for Blazor’s interactive client-side rendering. Verify that the documentation site is configured correctly to accommodate this rendering mode without issues.
3-6: All good to go.
The preview structure and snippet references appear correct. The snippet key "Select.Code.CustomStyles" should be verified to ensure that it matches an existing snippet identifier.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Disabled.razor (1)
1-11: Looks consistent.
Displaying disabled listbox items with a danger color is a straightforward approach for demonstration. Confirm that disabled items are clearly indicated to screen readers or other assistive technologies to ensure proper accessibility.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/DisabledItems.razor (1)
2-12: Approach is correct.
Marking items as disabled by matching their string Value in DisabledItems is a clear, easy-to-understand approach. This pattern should work as intended as long as item values remain unique within the listbox.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingSingle.razor (1)
15-17: Good use of two-way data binding.
Using a private field for _selectedValue simplifies the data-binding experience in this example. Looks solid.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/TwoWayDataBindingMultiple.razor (1)
1-13: Verify the multi-select UI behavior.
Ensure that unselecting items behaves as expected. It may be beneficial to confirm that removing one item from the list doesn't inadvertently clear all selections.
src/LumexUI/Components/Popover/LumexPopoverContent.razor (1)
4-8: Good asynchronous handling for outside clicks.
Switching to await the click handler ensures that any asynchronous logic (e.g., cleanup or data fetching before closing) completes properly. This helps avoid race conditions.
docs/LumexUI.Docs.Client/Common/Navigation/Types.cs (1)
31-31: Ensure references to ComponentStatus are updated across the codebase.
This change from NavItemStatus to ComponentStatus is correct in this constructor, but make sure all internal references (e.g., property usage, equality checks, or enum parsing) are updated accordingly.
Run the following script to confirm that there are no remaining references to NavItemStatus:
Also applies to: 34-34
✅ Verification successful
Let me also search for the new type to understand the context better:
No remaining references to NavItemStatus found in the codebase
The verification shows that:
- There are no remaining references to
NavItemStatusin the codebase - All usages of the new
ComponentStatusenum are consistent across the codebase, including:- Navigation components and badges
- Navigation store configurations
- Type definitions and parameters
The migration from NavItemStatus to ComponentStatus appears to be complete and consistent.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for any remnants of `NavItemStatus` usage.
rg -A 2 $'NavItemStatus'
Length of output: 23
Script:
#!/bin/bash
# Let's try a case-insensitive search to be thorough
rg -i "navitemstatus"
# Also search for files that might contain this enum
fd -e cs -x cat {} | grep -i "navitemstatus"
# Let's also check git history for recent changes related to this
git log -p --grep="NavItemStatus" --since="1 month ago"
Length of output: 68
Script:
#!/bin/bash
# Search for ComponentStatus usage
rg -i "componentstatus"
# Find all .cs files that might contain this type
fd -e cs -x cat {} | grep -i "componentstatus"
Length of output: 2036
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Required.razor (1)
3-3: Validate the mandatory requirements logic at runtime.
Using Required="@true" is correct to enforce selection. Ensure that any form-level validations or error messages are shown if a user does not select an item before submission. Likewise, Value="@("cat")" sets a default value—verify it aligns with the design intent if an explicitly empty selection is desired initially.
Also applies to: 4-4
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ReadOnly.razor (1)
3-3: Confirm that default value is displayed properly in read-only mode.
A read-only select with a default value of "cat" is valid. Verify that consumers of this component understand they cannot change this at runtime, and confirm it meets the design or business logic requirements.
Also applies to: 4-4
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/DisabledItems.razor (1)
1-3: Match DisabledItems with the dictionary data source.
Ensure that the items specified in DisabledItems—["elephant", "lion", "tiger"]—actually appear in _animals. Attempting to disable items that do not exist in the data source can produce inconsistencies or unexpected UI behavior.
src/LumexUI/Components/Listbox/ListboxContext.cs (2)
7-11: Consider thread-safety when managing _collectingItems and Items.
If there is any chance that these lists or flags will be accessed concurrently, you may need locking strategies or thread-safe collections to avoid race conditions.
21-24: Unregister method is straightforward, but verify potential item reuse cases.
Ensure that re-registering an item after unregistering it is supported or, if not, disallowed. This can prevent item duplication or references to disposed items.
docs/LumexUI.Docs.Client/Components/NavItemBadge.razor (1)
11-11: Check null handling when Status is not specified.
The code references Status!.Value inside _variants[Status!.Value]. This is protected by Status.HasValue, so at runtime it should be safe. Just be sure no external calls bypass that guard.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Description.razor (1)
14-30: Dictionary-based item list approach looks good.
Storing animals in a dictionary is a straightforward means of demonstration. For large sets, consider a more scalable data source or search-based approach.
src/LumexUI/Components/Listbox/ListboxItemSlots.cs (1)
12-38: Slots API design is flexible and well-documented.
Each slot property offers optional styling hooks. This makes item customization straightforward. Current documentation is clear and sufficient.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Usage.razor (1)
13-23: Great use of placeholder for guidance.
Having a dedicated placeholder for prompting users to choose an animal can enhance usability, especially if the list is long.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ItemStartEndContent.razor (2)
1-13: Nicely structured select with start content icons.
The approach of injecting a RenderFragment for the icon is well-designed and keeps the logic simple while providing a richer UI.
15-31: Validate flag asset availability.
Ensure that external flag URLs remain available and handle any potential loading errors gracefully. Consider adding fallback behavior if a flag fails to load or if the image URL is invalid.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/ErrorMessage.razor (3)
1-16: Responsive user feedback with ErrorMessage is excellent.
Dynamically updating the Invalid and ErrorMessage based on selection is a good UX pattern.
36-37: Defaulting validity might hide initial form validation.
Currently, _isValid defaults to true. If you require immediate validation on page load, you may consider rethinking the default or explicitly verifying the initial selection.
39-44: Smart validation approach.
The OnAnimalSelect method elegantly demonstrates how to handle dynamic validation by checking for "cat". Consider expanding it for more complex requirements.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/StartEndContent.razor (2)
1-12: Good use of StartContent for icon-based labeling.
This layout effectively conveys the purpose of each action.
14-34: Consistency in icon usage and fallback.
All icons rely on an external or shared icon set. If there's any chance the icons won't load, consider providing a text alternative or fallback.
src/LumexUI/Components/Listbox/LumexListbox.razor (6)
1-4: Clean usage of namespace and inheritance.
Good job defining the namespace and inheriting from LumexComponentBase. The use of @typeparam TValue provides flexibility for the component.
5-9: Ensure _context is properly initialized.
While _context is likely assigned outside of the snippet, ensure it's never null before invoking _context.StartCollectingItems(). If _context can be null in some scenarios, consider adding null checks or fail-fast patterns to improve reliability.
10-16: Good approach for deferring final item collection.
Using <Defer> to finalize the item collection after the child content is rendered is a solid pattern. This ensures that any dynamically added items are properly accounted for in _context.
24-35: Flexible approach to rendering items or empty content.
The inline condition for _context.Items.Count > 0 is straightforward. When no items exist, _renderEmptyContent is used. This is concise and easily extensible.
37-44: Efficient item rendering loop.
The RenderItems method delegates rendering to each item’s Render method. This approach ensures that each item has autonomy over its own rendering logic while still centralizing the iteration.
46-55: Appropriate usage of fallback content.
Using the EmptyContent property or _emptyContent fallback is a good user experience design, ensuring empty states are handled gracefully.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/StartEndContent.razor (5)
1-5: Neat usage of start content for visuals.
Including _petsIcon within the StartContent parameter helps illustrate the component’s customization possibilities.
6-12: Looping through _animals for dynamic items.
Using @foreach to generate LumexSelectItem elements is clear and concise. Ensure that each Value is unique.
14-18: End content usage is consistent.
Mirroring the _petsIcon logic at the end content is a nice touch to demonstrate symmetrical possibilities.
28-29: Good use of a RenderFragment for icons.
Defining _petsIcon as a RenderFragment allows easy reusability in other select components or scenarios.
31-46: Dictionary initialization is straightforward.
A flat dictionary is perfectly suitable here. If the list grows larger or becomes more dynamic, consider a data service or an API call.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Colors.razor (3)
1-1: Neat grid layout usage.
Organizing multiple selects in a grid with utility classes helps maintain responsiveness.
10-15: Looping through _animals is consistent with other examples.
The rely-on-dictionary approach is uniform, which eases the cognitive load for users reading across examples.
40-48: Comprehensive color list.
Presenting the array of theme colors here helps demonstrate the multiple theme functionalities. Future expansions might require an enum display name approach.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/ColorsVariants.razor (4)
1-10: Good example showing how color and variant can be combined.
The usage of LumexListboxItem with a distinct color highlights customization capabilities.
13-26: Fieldset for color selection is well-organized.
Having a dedicated section for selecting color via radio buttons encourages user experimentation and clarity in your docs.
28-41: Including a variant selection is a versatile approach.
Pairing different variants with colors highlights the modular nature of this component. It also helps illustrate real-world usage scenarios more concretely.
43-46: Sensible default values.
Using ThemeColor.Default and ListboxVariant.Solid as initial state is intuitive for new users who want a baseline experience.
src/LumexUI/Components/Select/Core/_ItemsCollectedNotifier.cs (4)
1-3: No issues found in the license header.
All good here.
14-18: Attributes comply with intended purpose.
Using [EditorBrowsable(EditorBrowsableState.Never)] and [SuppressMessage(...)] is valid for internal components.
19-21: Class structure looks solid.
Sealing the class is appropriate to prevent inheritance and keep this component purely internal.
34-56: Parameter handling logic is correct for first-render scenarios.
Only handling parameter setting on the first render is intentional. Ensure future changes don’t rely on _isFirstRender incorrectly if the LumexSelect<TValue>’s parameters need to be updated later.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/Description.razor (2)
1-22: Listbox usage and item structure look consistent.
Each LumexListboxItem is properly configured with a description and start content. Nice approach, especially for explaining file operations.
24-44: Icon render fragments are suitably organized.
Defining icons as RenderFragment fields keeps the code maintainable. The sizing and class usage appear coherent.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Sizes.razor (1)
1-34: Dynamic rendering of selects by size is a sound approach.
Iterating over Enum.GetValues<Size>() is a neat way to showcase multiple dimension options for the LumexSelect. The usage of _animals is properly integrated.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/Variants.razor (1)
1-34: Variant-based rendering effectively demonstrates customization.
Looping through Enum.GetValues<InputVariant>() is an intuitive way to show different styling. The code is cohesive and easy to follow.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/LabelPlacements.razor (2)
18-29: Incorporate ARIA considerations for placeholders.
When placeholders are used (line 20), ensure that screen readers can properly distinguish them from actual labels. In some contexts, placeholders may reduce accessibility unless accompanied by descriptive labels or instructions.
36-52: Good use of a predefined dictionary.
The _animals dictionary is well-organized and consistent with other examples across the codebase. This approach simplifies maintenance of shared sample data.
src/LumexUI/Components/Select/LumexSelectItem.cs (3)
16-16: Inheritance from LumexListboxItem<TValue> is appropriate.
Aligning with existing listbox patterns ensures uniform behavior and maintainability. This design choice appears to be a good fit here.
28-32: Null-check logic is solid.
Using ContextNullException.ThrowIfNull proactively detects improper usage of the LumexSelectItem, which helps maintain a robust state management. Great job on defensive programming!
55-60: Dispose pattern is well-implemented.
Properly unregistering from SelectContext ensures no memory leaks or invalid references for this item when it’s removed from the UI.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingSingle.razor (1)
3-6: Confirm that binding to _valueOne is intended.
The parameter uses @bind-Value="@_valueOne", stored as a nullable string. If the value can’t be null, consider changing _valueOne to a non-nullable type (e.g., string _valueOne = "cat").
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/TwoWayDataBindingMultiple.razor (1)
6-13: Usage of @bind-Values is correct.
Multiple-value selection is properly demonstrated. The snippet effectively shows how to bind to a collection.
src/LumexUI/Components/Listbox/LumexListboxItem.razor (1)
5-7: Ensure complementary unregistration.
You register this component in the context, but there's no corresponding Unregister(this) call upon disposal. Without unregistering, stale references to disposed components may remain.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomItems.razor (1)
1-4: Usage of <LumexSelect> is straightforward and clear.
This example illustrates a custom rendering of select items nicely. To further assist users, consider adding a brief comment explaining how <LumexSelect> pairs with <LumexSelectItem>.
src/LumexUI/Components/Popover/LumexPopoverContent.razor.cs (1)
71-74: Synchronous flow looks correct.
Awaiting HideAsync() first and then destroying the popover is logically consistent. Ensure error handling remains robust if HideAsync() fails.
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomValues.razor (1)
22-32: Check for null or default contexts to avoid runtime errors.
In the <ValueContent> block, _context may occasionally be null if no item is selected. Consider a conditional or fallback to handle an empty state, improving robustness.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Examples/CustomStyles.razor (2)
1-1: Validate CDN usage and caching strategy.
You load external icon assets from a CDN. Confirm that the CDN usage complies with performance and availability requirements, especially for production deployments.
64-65: Check icon presence or fallback in _icon.
If the icon name passed in is invalid or missing, consider a fallback icon or placeholder to prevent broken UIs.
docs/LumexUI.Docs.Client/Common/Navigation/NavigationStore.cs (3)
31-31: Confirm that LumexDataGrid<T> retains features from the previous status.
You changed the status to ComponentStatus.Preview. Confirm that the DataGrid features, previously associated with NavItemStatus.Preview, still function as expected and that other references to NavItemStatus are updated.
64-65: Ensure consistent naming of generic parameters.
LumexListbox<T> and LumexListboxItem<T> appear here. Confirm that the docs and references consistently use <T> or a more descriptive generic name, to avoid confusion in certain code samples.
77-78: Coordinate with newly added items.
Adding LumexSelect<T> and LumexSelectItem<T> expands the ecosystem. Confirm all references in the docs and sidebars for consistent naming and linking, so users can navigate effectively.
[approve]
docs/LumexUI.Docs.Client/Pages/Components/Select/Examples/CustomStyles.razor (4)
1-5: Maintain visual behavior consistency with other examples.
Using Classes="@_selectClasses", PopoverClasses="@_popoverClasses", and ListboxClasses="@_listboxClasses" is a solid approach. Ensure that other examples in the docs follow a similar pattern to reduce confusion for end-users.
24-34: Use fallback logic in <ValueContent> for null contexts.
Similar to other examples, always verify that @context is not null. An optional “placeholder” snippet or conditional check can avoid display errors if no selection is made.
78-82: Popover styling synergy.
You set p-0 border border-divider bg-background. Ensure it matches or complements the surrounding UI elements, so the popover appears cohesive with the rest of the page.
83-86: Mask usage caution.
The [mask-image:linear-gradient(...)] might be unsupported in older browsers. Consider a fallback or note in your docs about required browser support.
src/LumexUI/Components/Popover/LumexPopover.razor.cs (5)
82-86: Confirm resizing behavior for 'MatchRefWidth'.
When setting MatchRefWidth to true, ensure the popover’s width updates when the reference element’s width changes. If the reference can dynamically resize, consider re-computing popover positioning.
87-91: Use 'Opened' consistently across codebase.
Now that the internal boolean state IsShown is removed, confirm that all references to showing/hiding the popover now use Opened.
117-125: Asynchronous triggers are properly awaited.
Consider awaiting the returned task from TriggerAsync() at the call site if any subsequent logic depends on its completion. Failing to do so may lead to race conditions in advanced usage scenarios.
140-144: Validate hide logic matches user flow.
Setting Opened = false here might conflict if another popover is set to open just before or after. Ensure business logic prevents toggling states unexpectedly.
188-188: Synchronize MatchRefWidth usage in PopoverOptions.
MatchRefWidth in PopoverOptions must sync with the Popover’s actual resizing behavior. Verify that this property is referenced wherever popover dimensions are recalculated.
docs/LumexUI.Docs.Client/Pages/Components/Listbox/Listbox.razor (1)
143-201: Validate headings alignment with the docs layout.
The _headings and _compositionComponents arrays appear consistent with the rest of the doc system. Before merging, verify the layout navigation properly displays these sections in the correct order.
docs/LumexUI.Docs.Client/Pages/Components/Select/Select.razor (2)
139-154: Check correct usage of <DocsSlotsSection> vs <DocsSection>.
You’ve introduced <DocsSlotsSection> specifically for listing and describing named slots. Confirm that it suits your doc’s layout or if it can be consolidated into the main docs sections.
158-224: Ensure layout initialization is consistent with other components.
The _headings property and Layout.Initialize(...) call appear consistent. Confirm that the “API” and “Custom Styles” sections appear in the left sidebar in the intended order.
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Usage.razor
Show resolved
Hide resolved
docs/LumexUI.Docs.Client/Pages/Components/Select/PreviewCodes/Colors.razor
Show resolved
Hide resolved
1 participant
Closes #50
Summary by CodeRabbit
New Features
ComponentStatusenum with a new memberNew.Bug Fixes
Documentation
LumexSelectandLumexListbox, detailing usage, customization, and API references.Refactor