move everything to joins page, update search/default page, etc #82
Conversation
WalkthroughThe pull request introduces significant changes to the navigation and entity management within the application. The Changes
Possibly related PRs
Suggested reviewers
Poem
🪧 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: 4
🧹 Outside diff range and nitpick comments (9)
frontend/src/routes/+page.server.ts (1)
5-5: Consider using 308 (Permanent Redirect) instead of 307.Since this represents a permanent architectural change from models to joins, using HTTP status code 308 (Permanent Redirect) would be more appropriate than 307 (Temporary Redirect). This helps clients cache the redirect and search engines update their indices.
- throw redirect(307, '/joins'); + throw redirect(308, '/joins');frontend/src/lib/types/Entity/Entity.ts (3)
3-22: Consider extracting paths to a constants file.The path strings could be centralized in a separate constants file to maintain consistency and make updates easier.
// constants/routes.ts export const ROUTES = { MODELS: '/models', GROUPBYS: '/groupbys', JOINS: '/joins' } as const;Then update the config to use these constants:
export const entityConfig = [ { label: 'Models', - path: '/models', + path: ROUTES.MODELS, icon: Cube, id: 'models' }, // ... rest of the config ] as const;
24-25: Add JSDoc comments for better documentation.The types are well-defined, but could benefit from documentation.
+/** Represents an entity configuration with label, path, icon, and id. */ export type Entity = (typeof entityConfig)[number]; +/** Valid entity identifiers derived from the entity configuration. */ export type EntityId = Entity['id'];
27-32: Add input validation and improve error handling documentation.The helper function could be more robust with input validation and clearer documentation.
-// Helper function to get entity by ID +/** + * Retrieves an entity by its ID. + * @param id - The ID of the entity to retrieve + * @throws {Error} When the ID is undefined or when no entity matches the given ID + * @returns The matching entity + */ export function getEntity(id: EntityId): Entity { + if (!id) throw new Error('Entity ID is required'); const entity = entityConfig.find((entity) => entity.id === id); if (!entity) throw new Error(`Entity with id "${id}" not found`); return entity; }frontend/src/lib/types/Model/Model.ts (3)
26-30: Add JSDoc comments and consider type refinementsThe new
Jointype would benefit from documentation explaining its purpose and usage. Also, consider making thejoinFeaturestype more specific if these strings follow a particular format or come from a known set of values.+/** + * Represents a join configuration with its features and associated group-by dimensions. + */ export type Join = { name: string; - joinFeatures: string[]; + joinFeatures: JoinFeature[]; // Consider creating a specific type if features have a known format groupBys: GroupBy[]; };
32-35: Add JSDoc comments to GroupBy typeAdd documentation to explain the purpose and relationship with the Join type.
+/** + * Represents a group-by dimension with its associated features. + * @see Join + */ export type GroupBy = { name: string; features: string[]; };
Line range hint
38-46: Address TODOs and clarify type deprecation planThe TODOs indicate planned property renames, but given the PR's objective to move everything to the joins page, should this type be deprecated? Consider:
- Adding a deprecation notice if this type will be removed
- Creating a timeline for addressing the property renames
- Documenting the relationship between this type and the new
JointypeWould you like help creating a migration plan or implementing these changes?
frontend/src/routes/joins/+page.svelte (1)
23-23: Remove unusedActionButtonscomponent if not needed.The
ActionButtonscomponent is included but no actions are defined for it. If there are no actions to display for joins at this time, consider removing this component to clean up the UI.frontend/src/lib/components/NavigationBar/NavigationBar.svelte (1)
203-208: Remove 'onSelect' handlers from disabledCommandItemsSince these
CommandItems are disabled, theironSelecthandlers won't be invoked. Removing theonSelectprop can improve code clarity.Apply this diff to remove unnecessary
onSelecthandlers:<CommandItem - disabled - onSelect={() => - handleSelect(`${getEntity('models').path}/${encodeURIComponent(model.name)}`)} + disabled > <Icon src={getEntity('models').icon} micro size="16" /> {model.name} </CommandItem>And similarly for the groupBys:
<CommandItem disabled - onSelect={() => - handleSelect(`${getEntity('groupbys').path}/${encodeURIComponent(groupBy.name)}`)} > <Icon src={getEntity('groupbys').icon} micro size="16" /> {groupBy.name} </CommandItem>Also applies to: 219-226
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (8)
frontend/src/lib/components/NavigationBar/NavigationBar.svelte(3 hunks)frontend/src/lib/types/Entity/Entity.ts(1 hunks)frontend/src/lib/types/Model/Model.ts(2 hunks)frontend/src/routes/+layout.svelte(2 hunks)frontend/src/routes/+page.server.ts(1 hunks)frontend/src/routes/groupbys/+page.svelte(0 hunks)frontend/src/routes/joins/+page.svelte(1 hunks)frontend/src/routes/models/+page.svelte(0 hunks)
💤 Files with no reviewable changes (2)
- frontend/src/routes/groupbys/+page.svelte
- frontend/src/routes/models/+page.svelte
🔇 Additional comments (11)
frontend/src/routes/+page.server.ts (1)
5-5: LGTM! Verify impact on existing users.
The redirection change aligns with the architectural shift to joins-based navigation. However, we should ensure existing users are not disrupted.
Let's check for any hardcoded references to the old redirect path:
✅ Verification successful
Redirect change is safe to proceed
The redirection change from '/models' to '/joins' aligns with the architectural changes and is safe to implement because:
- The navigation structure has already been updated to filter for 'joins' only in the NavigationBar
- The entityConfig shows '/models' is no longer an active navigation item
- No other files in the codebase rely on the root path redirecting to '/models'
- The CommandDialog search functionality already handles both model and join paths correctly
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for hardcoded references to '/models' that might need updating
rg -g '!*.{md,json,lock}' '/models'
# Search for any tests that might be affected by this change
rg -g '*test*' -g '*spec*' '\/'
Length of output: 453
Script:
#!/bin/bash
# Search for hardcoded references to '/models' path in frontend code
rg -g '!*.{md,json,lock}' "'/models'" frontend/
# Search for hardcoded references to "/models" path in frontend code
rg -g '!*.{md,json,lock}' '"/models"' frontend/
# Search for test files that might be affected
fd -e test.ts -e spec.ts . frontend/
# Check navigation-related files for path references
rg -g '*.{svelte,ts}' "(path|href).*models" frontend/src/
Length of output: 398
Script:
#!/bin/bash
# Check the Entity.ts file to understand the context of '/models' usage
cat frontend/src/lib/types/Entity/Entity.ts
# Check test files for any model path dependencies
cat frontend/src/lib/api/api.test.ts
cat frontend/src/lib/types/Model/Model.test.ts
# Look for any navigation-related components
rg -g '*.svelte' -l "navigation|navbar|menu" frontend/src/
Length of output: 10578
Script:
#!/bin/bash
# Check the NavigationBar component and layout for navigation logic
cat frontend/src/lib/components/NavigationBar/NavigationBar.svelte
cat frontend/src/routes/+layout.svelte
# Check if there are any other files referencing the redirect
rg -g '*.{ts,svelte}' "redirect.*models|redirect.*joins" frontend/src/
Length of output: 8012
frontend/src/lib/types/Entity/Entity.ts (2)
1-1: LGTM! Icon imports are correctly defined.
3-22: Verify the inclusion of the /models path.
According to the PR objectives, content is being migrated from /models to /joins. Please verify if the /models path should still be included in the configuration.
✅ Verification successful
The /models path should remain in the configuration
The /models endpoint is still active and being used in the backend (/api/v1/models route and ModelController). There's no concrete evidence of a complete migration from models to joins, and the models functionality appears to be a core part of the system with dedicated controllers, routes, and model-related files across the codebase. While some content might be moving to joins, the models feature itself is still maintained.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for references to the /models path
rg -l "/models" --type svelte --type typescript
Length of output: 78
Script:
#!/bin/bash
# Check for references to the /models path in all files
rg -l "/models"
# Also check for any files with "model" in their path or content
fd "model"
Length of output: 696
Script:
#!/bin/bash
# Let's check the content of routes and controller to understand if /models endpoint is still active
cat hub/conf/routes | grep -i model
cat hub/app/controllers/ModelController.scala
# Also check for any recent changes or migrations related to models
rg -l "migration|migrate" --type ts --type scala
Length of output: 2308
Script:
#!/bin/bash
# Let's check the frontend routes and components to see if the models page is still actively used
rg -l "models.*route|route.*models" --type ts
# Also check for any components related to models page
fd -e svelte -e tsx -e jsx "Model"
# Check for any recent changes mentioning model to join migration
rg -l "move.*model.*join|migrat.*model.*join"
Length of output: 130
frontend/src/routes/+layout.svelte (3)
Line range hint 1-43: Overall component structure looks good
The layout component is well-structured with clear separation of concerns between navigation, breadcrumbs, and main content area. The use of ScrollArea for the main content is appropriate for handling overflow content.
9-9: Verify the Entity type structure
The import of entityConfig aligns with the PR objective of creating a shared entity object. Let's verify the structure of the Entity type to ensure it meets all requirements.
✅ Verification successful
The results show that entityConfig is properly structured with all necessary fields for navigation (label, path, icon, id). Let's verify if all the icons used in the config are properly imported and if there are any other components using this configuration to ensure the change is consistent.
Let's try one more verification with modified commands to check the usage of entityConfig across the frontend:
Entity type structure and usage is properly implemented
The verification confirms that:
entityConfigis properly structured with required navigation fields (label, path, icon, id)- Icons are correctly imported from 'svelte-hero-icons'
- The usage in
+layout.sveltecorrectly filters entities for navigation - The type definition is properly derived from the config
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the Entity type definition and configuration
# Expected: Entity type should include necessary fields for navigation (id, label, path, icon)
# Check Entity type definition
rg -A 10 "type Entity" frontend/src/lib/types/Entity/
# Check entityConfig implementation
rg -A 10 "entityConfig.*=" frontend/src/lib/types/Entity/
Length of output: 1727
Script:
#!/bin/bash
# Check icon imports in Entity.ts
rg -B 5 "export const entityConfig" frontend/src/lib/types/Entity/Entity.ts
# Find other components using entityConfig
rg "entityConfig" --type svelte
Length of output: 242
Script:
#!/bin/bash
# Find all files using entityConfig in the frontend directory
rg "entityConfig" frontend/
# Check if the icons are properly imported
ast-grep --pattern 'import { $$$ } from "svelte-hero-icons"'
Length of output: 577
26-26: Verify navigation paths after filtering change
The switch from hardcoded navigation items to filtered entityConfig represents a significant change in navigation structure.
✅ Verification successful
Navigation paths are correctly configured after filtering change
The filtering change to show only 'joins' navigation items is safe and properly implemented:
- The entityConfig structure is well-defined and includes the 'joins' entity with correct path '/joins'
- The NavigationBar component properly handles the filtered navItems prop
- All required routes exist (/joins/+page.svelte and /joins/[slug]/+page.svelte)
- The navigation paths in search functionality and links are consistent with the filtered navigation structure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential broken navigation paths
# Expected: All referenced routes should exist and be handled
# Check for route definitions
fd "\\+page" frontend/src/routes
# Check for references to old model paths that might break
rg -A 2 "/models/" frontend/src/
Length of output: 325
Script:
#!/bin/bash
# Let's verify the navigation structure and entityConfig usage
# Check the entityConfig definition and structure
rg -l "entityConfig" frontend/src/
# Look for NavigationBar component usage and its props
rg -A 3 "<NavigationBar" frontend/src/
# Check for any joins-related routing or configuration
rg -A 3 "joins" frontend/src/
Length of output: 2072
Script:
#!/bin/bash
# Let's examine the entityConfig structure and its usage in navigation
# Check the full entityConfig definition
cat frontend/src/lib/types/Entity/Entity.ts
# Look for the NavigationBar component implementation
cat frontend/src/lib/components/NavigationBar/NavigationBar.svelte
Length of output: 7126
frontend/src/routes/joins/+page.svelte (3)
38-57: Ensure all model properties are defined to prevent runtime errors.
In the {#each models as model} loop, make sure that all the properties used (model.join, model.name, model.team, model.modelType, model.online, model.production) are defined for every model. If any of these properties might be undefined, consider adding default values or conditional rendering to prevent runtime errors.
51-54: Confirm prop names for the TrueFalseBadge component.
Ensure that the TrueFalseBadge component accepts the isTrue prop. If the prop name is different (e.g., value or status), update it accordingly to match the component's API.
16-17:
Correct the invalid usage of $props() and $state().
The syntax $props() and $state() is not standard in Svelte or SvelteKit. To access props and reactive data in Svelte, you should use export let and standard variable assignments. Here's how you can fix it:
-const { data } = $props();
-const models: Model[] = $state(data.models.items);
+export let data;
+const models: Model[] = data.models.items;Likely invalid or redundant comment.
frontend/src/lib/components/NavigationBar/NavigationBar.svelte (2)
35-38: LGTM: Integration of 'Entity' type and 'getEntity' function
The import of getEntity and updating navItems to type Entity[] aligns the component with the new entity structure. This enhances consistency and maintainability.
132-134: Navigation items updated to use 'item.path' and 'item.icon'
The change from item.href to item.path and adjustments to the Icon component correctly reflect the updated Entity structure.
Also applies to: 141-141
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
frontend/src/lib/components/NavigationBar/NavigationBar.svelte (1)
133-142: Enhance accessibility for navigation itemsWhile the navigation rendering changes are functionally correct, consider adding ARIA labels to improve accessibility.
Apply this diff to enhance accessibility:
<Button variant={isActiveRoute(item.path) ? 'default' : 'ghost'} size="nav" href={item.path} icon="leading" + aria-label={`Navigate to ${item.label}`} + aria-current={isActiveRoute(item.path) ? 'page' : undefined} >
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
frontend/src/lib/components/NavigationBar/NavigationBar.svelte(3 hunks)
🔇 Additional comments (2)
frontend/src/lib/components/NavigationBar/NavigationBar.svelte (2)
36-36: LGTM: Type changes align with entity restructuring
The introduction of the Entity type and updates to the Props interface are well-structured and properly typed.
Also applies to: 39-39
205-212: Verify if models should be disabled in search results
The model items are marked as disabled, but according to the PR objectives, this might be inconsistent. The PR mentions that "users cannot click on a model or groupby from the search results" - is this intentional or should models be clickable?
Run the following script to check if models are meant to be disabled across the codebase:
✅ Verification successful
Models and groupBys are intentionally disabled in search results
After reviewing the code, the disabled state for models and groupBys in search results is intentional and consistent with the implementation. The code shows:
- Models are consistently marked as disabled in search results
- Only join items are clickable/selectable
- This aligns with the PR objective stating "users cannot click on a model or groupby from the search results"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other instances of model navigation/linking
# to verify if models should be disabled consistently
# Check for model navigation patterns
rg -A 3 "model.*path|model.*href|model.*link" --type svelte
# Check for disabled patterns with models
rg "disabled.*model|model.*disabled" --type svelte
Length of output: 176
Script:
#!/bin/bash
# Description: Check for other instances of model navigation/linking
# to verify if models should be disabled consistently
# Check for model navigation patterns in all files
rg -A 3 "model.*path|model.*href|model.*link"
# Check for disabled patterns with models in all files
rg "disabled.*model|model.*disabled"
# Check the specific component for context
cat frontend/src/lib/components/NavigationBar/NavigationBar.svelte
Length of output: 7566
| <CommandItem | ||
| disabled | ||
| onSelect={() => | ||
| handleSelect(`${getEntity('models').path}/${encodeURIComponent(model.name)}`)} | ||
| > | ||
| <Icon src={getEntity('models').icon} micro size="16" /> | ||
| {model.name} | ||
| </CommandItem> | ||
| <CommandItem | ||
| onSelect={() => | ||
| handleSelect(`${getEntity('joins').path}/${encodeURIComponent(model.join.name)}`)} | ||
| > | ||
| <Icon src={getEntity('joins').icon} micro size="16" /> | ||
| {model.join.name} | ||
| </CommandItem> | ||
| {#each model.join.groupBys as groupBy} | ||
| <CommandItem | ||
| disabled | ||
| onSelect={() => | ||
| handleSelect(`${getEntity('groupbys').path}/${encodeURIComponent(groupBy.name)}`)} | ||
| > | ||
| <Icon src={getEntity('groupbys').icon} micro size="16" /> | ||
| {groupBy.name} | ||
| </CommandItem> | ||
| {/each} |
There was a problem hiding this comment.
💡 Codebase verification
Based on the search results, I can now generate a final response:
Backend search endpoint needs to be updated for new entity types
The current search implementation in SearchController.scala only supports searching model names, but the frontend is now displaying joins and groupBys in search results. The backend needs to be extended to support these entity types.
hub/app/controllers/SearchController.scala: Comment explicitly states "currently we only support searching model names"frontend/src/lib/api/api.ts: Frontend search function returnsModelsResponsetype, suggesting backend only returns models
🔗 Analysis chain
Verify search implementation for new entity types
The search results now include joins and groupBys. Let's verify that the backend search endpoint properly handles these new entity types.
Run the following script to check the search implementation:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify search endpoint implementation for new entity types
# Check the search endpoint implementation
rg -A 10 "search.*function|search.*endpoint" --type typescript
# Check for join/groupBy handling in search-related code
rg -A 5 "join.*search|groupBy.*search" --type typescript
Length of output: 193
Script:
#!/bin/bash
# Let's try without typescript file type and use more specific patterns
# Check search-related implementations
rg -A 10 'search.*function|search.*endpoint|function.*search'
# Check for join/groupBy handling in search-related code
rg -A 5 'join.*search|groupBy.*search|search.*join|search.*groupBy'
# Look for API routes or handlers related to search
fd -e ts -e js "search" --exec cat {}
Length of output: 5185
There was a problem hiding this comment.
@piyush-zlai This is relevant - search only works for at the model level. i.e. a search of "foo" will not match a model named "bar" with a join named "foo"
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
frontend/src/routes/joins/+page.svelte (1)
1-60: Add unit tests for the joins page.The PR objectives mention that unit tests haven't been added yet. Consider adding tests for:
- Table rendering with various model states
- URL encoding edge cases
- Empty/undefined model handling
Would you like me to help generate unit test templates for this component?
frontend/src/lib/types/Model/Model.test.ts (1)
Line range hint
1-240: Consider adding specific nullValue test casesWhile the tests verify the presence of 'nullValue' in the response structure, they don't explicitly test scenarios where nullValue is present or its impact on data visualization/handling.
Consider adding test cases that specifically verify:
- Responses with null values
- Responses with mixed null and non-null values
- Edge cases in data visualization with null values
Example test structure:
it('should handle null values in time series data', async () => { const timeseriesResult = await api.getModelTimeseries( modelName, startTime, endTime ); const nullValueItem = timeseriesResult.items.find(item => item.nullValue === true); expect(nullValueItem).toBeDefined(); expect(nullValueItem?.value).toBeNull(); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
frontend/src/lib/types/Model/Model.test.ts(2 hunks)frontend/src/routes/joins/+page.svelte(1 hunks)
🔇 Additional comments (4)
frontend/src/routes/joins/+page.svelte (3)
41-41: URL encoding implementation looks good.
The suggested URL encoding from the previous review has been properly implemented.
22-24: Clarify the purpose of ActionButtons component.
The ActionButtons component is included but its functionality isn't clear from the context. Please specify what actions are available and how they relate to the joins page.
✅ Verification successful
Let me search for more context about the ActionButtons component implementation.
ActionButtons component provides standard data manipulation controls
The ActionButtons component is a reusable UI element that provides standard data manipulation controls including:
- Filter button to filter data
- Sort button to sort data
- Optional cluster button (when showCluster prop is true)
The implementation is clear and follows common patterns for data table/list controls. No issues found with its usage on the joins page.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Look for ActionButtons implementation to understand available actions
ast-grep --pattern 'export const actions = $_'
rg -A 10 'ActionButtons\.svelte'
Length of output: 1829
Script:
#!/bin/bash
# Look for ActionButtons component implementation
fd ActionButtons.svelte --exec cat {}
Length of output: 1394
1-17: Verify Svelte 5 compatibility in production.
The code uses Svelte 5 features ($props(), $state). While the implementation is correct, ensure that your production environment and CI/CD pipeline are configured to handle Svelte 5 syntax.
✅ Verification successful
Svelte 5 usage is consistent with project configuration
The codebase is properly configured with Svelte 5 ("svelte": "^5.0.4"), and the $props() and $state syntax is consistently used across multiple components in the frontend. The implementation in /joins/+page.svelte aligns with the project's established patterns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check package.json for Svelte version
cat package.json | jq '.dependencies.svelte, .devDependencies.svelte'
# Look for other Svelte 5 usage patterns in the codebase
rg -l '\$props\(\)|\$state\(' --type svelte
Length of output: 193
Script:
#!/bin/bash
# Try to find package.json files recursively
fd package.json
# Look for Svelte version patterns in package.json files
fd package.json -x cat {} | grep -i "svelte"
# Search for Svelte 5 syntax patterns without file type filter
rg -l '\$props\(\)|\$state\('
# Look for any svelte config files that might indicate version
fd -e js -e cjs -e ts -e json -g '*svelte*'
Length of output: 1831
frontend/src/lib/types/Model/Model.test.ts (1)
74-74: Verify handling of nullValue in TimeSeriesResponse
The addition of 'nullValue' to expected keys suggests a schema change. Ensure that the corresponding Model.ts type definitions and API documentation are updated to reflect this change.
✅ Verification successful
nullValue field is correctly defined in TimeSeriesItem type
The nullValue field is properly defined in the TimeSeriesItem type in frontend/src/lib/types/Model/Model.ts. The test's expected keys match the actual type definition which includes value, ts, label, and nullValue as a number field. The schema change is consistently reflected in both the type definition and tests.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if Model.ts includes nullValue in type definitions
rg -A 5 "interface.*TimeSeriesResponse"
Length of output: 41
Script:
#!/bin/bash
# Let's try searching for TimeSeriesResponse in all files
rg "TimeSeriesResponse" -A 5
# Also search for type definitions containing nullValue
rg "type.*\{[^}]*nullValue" -A 5
Length of output: 13124
Script:
#!/bin/bash
# Let's check the TimeSeriesItem type definition which should contain the nullValue field
ast-grep --pattern 'type TimeSeriesItem = {
$$$
}'
# Also check for any interfaces or types containing nullValue
ast-grep --pattern 'type $_ = {
$$$
nullValue: $_
$$$
}'
Length of output: 829
Summary
I have moved everything from
/models/model_nameto/joins/join_name. I also created a shared entity object and show groupbys and joins in search results. PR walkthrough video hereLimitations:
Future:
Checklist
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Removals
These updates improve user navigation and provide a more informative interface for managing joins and models.