Add ModalService to Boilerplate (#9323) #9324
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughA new Changes
Assessment against linked issues
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Outside diff range and nitpick comments (10)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalData.cs (3)
3-4: Add XML documentation for the public class and constructor parameters.Since this is a public class in a core service, adding XML documentation would improve maintainability and provide better IntelliSense support for consumers.
+/// <summary> +/// Represents the data structure for modal dialogs. +/// </summary> +/// <param name="type">The type of component to be rendered in the modal.</param> +/// <param name="parameters">Optional parameters to be passed to the component.</param> +/// <param name="title">Optional title of the modal dialog.</param> +/// <param name="taskCompletionSource">Task completion source for handling modal dialog results.</param> public partial class ModalData(Type type, IDictionary<string, object>? parameters, string? title, TaskCompletionSource<bool> taskCompletionSource)
5-11: Consider making properties init-only for immutability.Since all properties are initialized through the constructor, making them init-only would prevent unintended modifications after initialization and promote immutability.
- public Type ComponentType { get; set; } = type; + public Type ComponentType { get; init; } = type; - public IDictionary<string, object>? Parameters { get; set; } = parameters; + public IDictionary<string, object>? Parameters { get; init; } = parameters; - public string? Title { get; set; } = title; + public string? Title { get; init; } = title; - public TaskCompletionSource<bool> TaskCompletionSource { get; set; } = taskCompletionSource; + public TaskCompletionSource<bool> TaskCompletionSource { get; init; } = taskCompletionSource;
7-7: Consider using IReadOnlyDictionary for Parameters property.Since the Parameters dictionary is used for passing data to components, using
IReadOnlyDictionarywould better express the intent and prevent unintended modifications.- public IDictionary<string, object>? Parameters { get; init; } = parameters; + public IReadOnlyDictionary<string, object>? Parameters { get; init; } = parameters?.AsReadOnly();src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.scss (2)
3-11: Consider using a class selector instead of element selectorUsing direct element selectors (
section) can be risky for maintainability as it affects all section elements within the scope. Consider using a more specific class selector.-section { +.modal-container { padding: 1rem; min-width: 20rem; max-height: var(--app-height); @include lt-md { min-width: unset; } }
23-32: Consider extracting the magic number into a CSS variableThe stack height calculation uses a magic number (
3rem). Consider extracting this into a CSS variable for better maintainability.+:root { + --modal-stack-offset: 3rem; +} .stack { - max-height: calc(var(--app-height) - 3rem); + max-height: calc(var(--app-height) - var(--modal-stack-offset)); }src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor (2)
5-18: Improve semantic structure and button accessibilityThe header section needs semantic HTML elements and better accessibility for the close button.
Consider these improvements:
<section> <BitStack Class="stack"> - <BitStack Horizontal AutoHeight> + <header> + <BitStack Horizontal AutoHeight Class="modal-header"> <BitText Typography="BitTypography.H5" Color="BitColor.Tertiary"> @title </BitText> <BitSpacer /> <BitButton OnClick="OnCloseClick" Color="BitColor.Tertiary" Variant="BitVariant.Text" + AriaLabel="Close modal" IconName="@BitIconName.ChromeClose" /> - </BitStack> + </BitStack> + </header>
1-27: Consider enhancing modal capabilities and architectureThe current implementation could benefit from additional features and better architecture.
Consider these architectural improvements:
- Add support for different modal sizes:
[Parameter] public ModalSize Size { get; set; } = ModalSize.Medium;
- Add backdrop click handling:
[Parameter] public bool CloseOnBackdropClick { get; set; } = true;
- Consider implementing a render fragment for custom header content:
[Parameter] public RenderFragment HeaderContent { get; set; }
- Add support for modal stacking and z-index management through the ModalService.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs (1)
1-44: Consider separating modal management from display logicThe current implementation combines queue management with modal display logic. Consider splitting these responsibilities:
IModalQueueManagerfor managing the queue of modal requestsIModalDisplayServicefor handling the actual display of modalsIModalServiceas a facade coordinating between the twoThis separation would:
- Improve testability
- Make the code more maintainable
- Allow for different modal display implementations
Would you like me to provide a detailed implementation of this architectural improvement?
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs (2)
1-13: Add XML documentation and consider thread safetyThe class structure looks good, but consider adding XML documentation for the public class to improve maintainability. Also, since
TaskCompletionSourceand state variables are accessed from async contexts, consider using volatile or synchronization mechanisms for thread safety.+/// <summary> +/// Modal component that handles dynamic content rendering and modal state management. +/// </summary> public partial class Modal : AppComponentBase
1-60: Consider adding modal lifecycle eventsThe current implementation handles basic modal functionality well. Consider enhancing it with lifecycle events (OnBeforeOpen, OnAfterClose, etc.) to allow consumers to hook into modal state changes. This would improve flexibility for scenarios like animations or state cleanup.
Example enhancement:
public delegate Task ModalLifecycleEventHandler(ModalLifecycleEventArgs args); public event ModalLifecycleEventHandler? OnBeforeOpen; public event ModalLifecycleEventHandler? OnAfterClose;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (9)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.scss(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/RootLayout.razor(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Extensions/IClientCoreServiceCollectionExtensions.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientPubSubMessages.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalData.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/compilerconfig.json(1 hunks)
🔇 Additional comments (13)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalData.cs (1)
1-12: Verify the integration with ModalService.
The class looks well-structured for modal dialog management. Let's verify its usage in the ModalService to ensure proper integration.
✅ Verification successful
Let me gather more information about the ModalService implementation to verify the integration properly.
Integration between ModalData and ModalService is properly implemented
The verification shows a well-structured integration:
- ModalService maintains a queue of ModalData instances and processes them sequentially
- Modal component correctly handles ModalData through PubSub messaging
- TaskCompletionSource is properly managed throughout the lifecycle
- Clean disposal and state management is implemented
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find and analyze the ModalService implementation and its usage of ModalData
# Find ModalService implementation
echo "Looking for ModalService implementation..."
rg -l "class.*ModalService"
# Find usages of ModalData
echo "Looking for ModalData usages..."
rg "ModalData" --type cs -A 5
Length of output: 2797
Script:
#!/bin/bash
# Get the full implementation of ModalService to verify integration
echo "ModalService implementation:"
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
# Get the Modal component implementation to understand the complete flow
echo -e "\nModal component implementation:"
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs
Length of output: 2839
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.scss (3)
14-21: LGTM! Well-structured positioning using CSS variables
The use of CSS variables for dimensions and positioning provides good flexibility and maintainability.
13-41: Consider the implications of deep selectors
While ::deep selectors are sometimes necessary in Blazor components, extensive use can make styles harder to override and maintain. Consider:
- Documenting the expected structure of nested components
- Verifying that all CSS variables are properly defined in the root layout
✅ Verification successful
Deep selectors are appropriately used with proper CSS variable definitions
The use of ::deep selectors in the Modal component is justified as:
- All CSS variables (
--app-width,--app-height,--app-inset-*) are properly defined in the root app.scss - The variables handle both LTR/RTL layouts and safe area insets for different devices
- The deep selectors are used minimally and only for essential layout properties
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for CSS variable definitions in layout files
rg -l "app-(width|height|inset)" --type css --type scss
Length of output: 86
Script:
#!/bin/bash
# Search for CSS variable definitions without file type restrictions
rg "app-(width|height|inset)"
# Also search for any SCSS files to verify file extension handling
fd -e scss
Length of output: 43068
Script:
#!/bin/bash
# Check the content of app.scss for CSS variable definitions
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Styles/app.scss
Length of output: 2201
34-40: Review white-space handling for potential overflow issues
The white-space: pre property preserves all whitespace and might cause horizontal scrolling with long content. Consider using white-space: pre-wrap if you want to preserve formatting while allowing text wrapping.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor (1)
1-27: Verify integration with ModalService
Let's ensure this component properly integrates with the ModalService mentioned in the PR objectives.
✅ Verification successful
Modal component properly integrates with ModalService
The verification confirms proper integration between the Modal component and ModalService:
- The Modal component subscribes to
ClientPubSubMessages.SHOW_MODALevents and handles modal display - ModalService implements a queue-based system to show modals and publishes events through PubSubService
- The communication flow is complete with proper data passing (ModalData) and task completion handling
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for ModalService usage in the component's code-behind file
rg -t cs "ModalService" $(dirname "src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor")
# Verify service registration
rg -t cs "services\.AddScoped<.*ModalService>"
Length of output: 285
Script:
#!/bin/bash
# Let's check for the Modal.razor.cs file specifically
fd "Modal.razor.cs" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout --exec cat {}
# Search for any service registration patterns in Program.cs or similar startup files
fd "Program.cs|Startup.cs" src/Templates/Boilerplate/Bit.Boilerplate/src/Client --exec cat {}
# Look for any ModalService class definition
rg -t cs "class.*ModalService"
# Search for any modal-related service implementations
rg -t cs "interface.*Modal.*Service"
Length of output: 23287
Script:
#!/bin/bash
# Let's check the ModalService implementation and its usage
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
# Check for PubSubService usage in Modal component
rg -t cs "ClientPubSubMessages.SHOW_MODAL"
# Check for ModalData class definition
rg -t cs "class ModalData"
Length of output: 1834
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ClientPubSubMessages.cs (2)
9-9: LGTM! The constant follows established patterns.
The new constant follows the project's naming conventions and uses the nameof operator consistently with other constants.
9-9: Verify the relationship between modal message types.
Please clarify the distinction between SHOW_MODAL and SHOW_DIAGNOSTIC_MODAL. Consider documenting their specific use cases to prevent confusion.
Also applies to: 23-23
✅ Verification successful
Based on the search results, I can now generate the final response as the distinction between the two modal types is clear from their usage patterns:
The modal message types serve distinct purposes and are correctly separated
SHOW_MODAL is used for general-purpose modals through the ModalService, while SHOW_DIAGNOSTIC_MODAL is specifically used for diagnostic/error-related scenarios in components like AppErrorBoundary, JsBridge, and DiagnosticModal. Their implementations and subscriptions are properly separated:
Modal.razor.cssubscribes toSHOW_MODALfor general modal dialogsDiagnosticModal.razor.cssubscribes toSHOW_DIAGNOSTIC_MODALfor error diagnosticsSHOW_DIAGNOSTIC_MODALis consistently used across error handling components
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for usages of both modal message types to understand their distinct purposes
# Search for SHOW_MODAL usage
echo "=== SHOW_MODAL usage ==="
rg -A 5 "SHOW_MODAL[^_]"
# Search for SHOW_DIAGNOSTIC_MODAL usage
echo -e "\n=== SHOW_DIAGNOSTIC_MODAL usage ==="
rg -A 5 "SHOW_DIAGNOSTIC_MODAL"
# Search for Modal component subscriptions
echo -e "\n=== Modal component message subscriptions ==="
ast-grep --pattern 'Subscribe<$_>($_, $_, $_)'
Length of output: 7061
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/RootLayout.razor (2)
47-49: Consider potential functional overlap with existing dialog components
The codebase already includes MessageBox and DiagnosticModal components. Consider documenting the specific use cases for each dialog type to prevent confusion and maintain clear separation of concerns.
✅ Verification successful
Let me try a different search strategy to find more information about these components and their usage.
Let me check the content of these service files to understand their purposes and relationships.
Based on the comprehensive analysis of the codebase, I can now provide a final response:
Each dialog component serves a distinct purpose with clear separation of concerns
The components have well-defined roles:
Modal: A general-purpose container for custom content with positioning, dragging, and styling capabilitiesMessageBox: Specifically for displaying messages/alerts with a simple message and titleDiagnosticModal: A specialized modal for displaying diagnostic information, triggered by Ctrl+Shift+X
The implementation shows clear separation through:
- Dedicated services (
ModalService,MessageBoxService) managing their own queues and lifecycles - Different use cases in the codebase (e.g., MessageBox for error handling, Modal for product editing)
- Distinct styling and behavior options for each component type
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage patterns of existing dialog components
ast-grep --pattern 'class $_ {
$$$
Show$_($$$) {
$$$
}
$$$
}'
# Look for any documentation about dialog usage
fd -e md -e txt . | xargs rg -i "modal|dialog|messagebox|diagnostic"
Length of output: 634
Script:
#!/bin/bash
# Search for Modal, MessageBox, and DiagnosticModal component definitions
ast-grep --pattern 'class $name : ComponentBase {
$$$
}'
# Search for specific usages of these components
rg -l "Modal|MessageBox|DiagnosticModal" --type=razor
# Look for service classes that might handle these dialogs
rg -l "DialogService|ModalService|MessageBoxService" --type=cs
Length of output: 1830
Script:
#!/bin/bash
# Check the content of Modal and MessageBox service implementations
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
cat src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/MessageBoxService.cs
# Search for razor components with .razor extension
fd -e razor | xargs rg -l "Modal|MessageBox|DiagnosticModal"
# Look for component usages in the codebase
rg "Modal|MessageBox|DiagnosticModal" --type=cs -A 2 -B 2
Length of output: 128680
47-47: Verify z-index layering with existing components
The Modal component is correctly placed outside the main content area alongside other overlay components. However, ensure proper z-index layering is implemented to handle cases where multiple overlays (Modal, SnackBar, MessageBox) need to be shown simultaneously.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Extensions/IClientCoreServiceCollectionExtensions.cs (3)
42-42: LGTM: Service registration aligns with architectural patterns.
The ModalService registration:
- Uses
AddSessionedcorrectly for platform-specific lifetime management - Groups logically with other UI-related services
- Follows the established service registration patterns
Line range hint 42-46: Verify service dependencies and initialization order.
The new service registrations look good, but let's verify the dependencies:
ModalServicemight depend onPubSubServicefor communicationNoopLocalHttpServeris registered after its potential consumers
Consider:
- Documenting the dependency relationships between these services in code comments
- Ensuring the registration order matches the dependency graph to prevent potential initialization issues
✅ Verification successful
Service registration order is appropriate
The verification shows that:
ModalServicedepends onPubSubService(via[AutoInject]), confirming that the registration order inIClientCoreServiceCollectionExtensions.csis correct sincePubSubServiceis registered right afterModalService.NoopLocalHttpServeris a simple implementation with no dependencies, and its consumers (SignInPage,SignUpPage) inject it via[AutoInject], making the registration order non-critical.- Platform-specific implementations (
WindowsLocalHttpServer,MauiLocalHttpServer) are registered separately in their respective platform projects.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for ModalService dependencies and usage
ast-grep --pattern 'class ModalService {
$$$
constructor($_) {
$$$
}
$$$
}'
# Search for NoopLocalHttpServer dependencies
ast-grep --pattern 'class NoopLocalHttpServer : ILocalHttpServer {
$$$
}'
Length of output: 399
Script:
#!/bin/bash
# Search for ModalService class and its dependencies using ripgrep
rg -l "class ModalService" --type-add 'cs:*.cs' -tcs
# Search for constructor dependencies in files containing ModalService
rg "ModalService.*\(.*\)" --type-add 'cs:*.cs' -tcs -A 2
# Search for NoopLocalHttpServer implementation and usage
rg "class NoopLocalHttpServer" --type-add 'cs:*.cs' -tcs -A 5
# Search for ILocalHttpServer usage to understand dependencies
rg "ILocalHttpServer" --type-add 'cs:*.cs' -tcs -A 2
Length of output: 6996
Script:
#!/bin/bash
# Let's check the ModalService implementation for dependencies
rg -A 10 "class ModalService" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
# Check if PubSubService is used within ModalService
rg "PubSubService" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
# Check the order of service initialization in SignInPage and SignUpPage
rg "OnInitialized|OnInitializedAsync" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/Sign*/SignInPage.razor.cs src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/Sign*/SignUpPage.razor.cs -A 5
Length of output: 957
Line range hint 42-46: Verify Modal functionality integration.
The service registrations align with the PR objectives. To ensure complete integration:
✅ Verification successful
Let me analyze the verification needed and generate appropriate scripts to check the Modal functionality integration.
I'll verify:
- The ModalService implementation
- How ModalService is being used in the codebase
- Any related Modal interfaces/contracts
This will help ensure the Modal functionality is properly integrated into the codebase.
Let me analyze the results and generate a final response based on the findings.
Modal functionality integration verified successfully.
The implementation appears complete and properly integrated:
- The ModalService is properly registered in the dependency injection container using
AddSessioned<ModalService>() - The ModalService class exists with required infrastructure:
- Uses ConcurrentQueue for managing modal operations
- Has state management via isRunning flag
- It's integrated alongside other UI services (PubSubService, SnackBarService, MessageBoxService) following consistent patterns
The service registration aligns with the PR objectives and follows the project's architectural patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify Modal component and service integration
rg -A 5 "ModalService"
# Check for any TODO comments or incomplete implementations
rg -i "todo.*modal|fixme.*modal"
Length of output: 133004
Script:
#!/bin/bash
# Check for Modal component implementation
ast-grep --pattern 'class ModalService {
$$$
}'
# Check for Modal usage/references
rg -A 3 "ModalService" --type cs
# Check for any Modal-related interfaces
ast-grep --pattern 'interface $name {
$$$
Modal$$$
$$$
}'
Length of output: 1645
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/compilerconfig.json (1)
39-44: LGTM! Configuration follows project conventions.
The configuration for Modal.razor.scss follows the established pattern and maintains consistency with other component style configurations.
Let's verify the existence of the referenced files and potential naming conflicts:
✅ Verification successful
✅ Configuration and files are properly set up
The verification confirms:
- Modal.razor.scss exists in the correct location
- The component follows the established pattern alongside other modal components (DiagnosticModal)
- No naming conflicts exist as other modal components (AddOrEditProductModal) are in different directories
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Modal component files exist and check for potential conflicts
# Check if the SCSS file exists
fd --type f "Modal.razor.scss" "Components/Layout"
# Look for other modal-related components to check for potential conflicts
fd --type f ".*Modal.*" "Components"
Length of output: 288
Script:
#!/bin/bash
# Let's correct the paths by searching from the repository root
# First, find the exact location of the compilerconfig.json to determine the correct base path
fd compilerconfig.json
# Then use that path information to construct correct search paths
fd --type f "Modal.razor.scss" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout
# Look for other modal-related components
fd --type f ".*Modal.*" src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components
Length of output: 2305
...Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor
Show resolved
Hide resolved
...Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor
Outdated
Show resolved
Hide resolved
...Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor
Show resolved
Hide resolved
...ates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
Outdated
Show resolved
Hide resolved
...ates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
Show resolved
Hide resolved
...ates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/ModalService.cs
Show resolved
Hide resolved
...lerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs
Outdated
Show resolved
Hide resolved
...lerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs
Outdated
Show resolved
Hide resolved
...lerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs
Outdated
Show resolved
Hide resolved
...lerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Layout/Modal.razor.cs
Outdated
Show resolved
Hide resolved
closes #9323
Summary by CodeRabbit
Release Notes
New Features
Modalcomponent for displaying modal dialogs with dynamic content.ModalServiceto manage modal requests in a concurrent environment.ModalDataclass to encapsulate modal data.Styling
Service Enhancements
ModalServicefor session-specific modal management.Documentation