Skip to content

feat(settings): support plain field-id keys for dependency lookups (#90)#94

Merged
kzamanbd merged 1 commit into
mainfrom
settings/field-id-deps
May 22, 2026
Merged

feat(settings): support plain field-id keys for dependency lookups (#90)#94
kzamanbd merged 1 commit into
mainfrom
settings/field-id-deps

Conversation

@kzamanbd
Copy link
Copy Markdown
Contributor

@kzamanbd kzamanbd commented May 22, 2026

Plugin-ui's formatSettingsData() rebuilds dependency_key as a dot-path (parent.child.field) and the values map is keyed by that dot-path. Dependencies declared with a plain field id (e.g., 'commission_type' instead of 'commission.commission.commission_type') therefore failed to resolve via values[dep.key].

Add an id-keyed fallback so both formats work side by side:

  • Export buildIdIndex(schema) from settings-formatter — produces a { field_id: dependency_key } map from the hierarchical schema.
  • evaluateDependencies() accepts an optional idIndex argument. When values[dep.key] is undefined and an idIndex is supplied, the function resolves dep.key as a field id and re-reads values via the index.
  • SettingsProvider builds the idIndex (memoised on schema) and threads it through shouldDisplay → evaluateDependencies.

Backwards compatible: callers that don't pass idIndex see identical behavior. Consumers whose backend guarantees globally-unique field ids (e.g., flat-storage schemas) can now use id-keyed dependencies, which stay valid across structural moves (no parent path to update).

Summary by CodeRabbit

  • Refactor
    • Improved internal performance of settings dependency resolution through optimized field indexing.

Review Change Stack

Plugin-ui's formatSettingsData() rebuilds dependency_key as a dot-path
(parent.child.field) and the values map is keyed by that dot-path.
Dependencies declared with a plain field id (e.g., 'commission_type'
instead of 'commission.commission.commission_type') therefore failed to
resolve via values[dep.key].

Add an id-keyed fallback so both formats work side by side:

- Export buildIdIndex(schema) from settings-formatter — produces a
  { field_id: dependency_key } map from the hierarchical schema.
- evaluateDependencies() accepts an optional idIndex argument. When
  values[dep.key] is undefined and an idIndex is supplied, the function
  resolves dep.key as a field id and re-reads values via the index.
- SettingsProvider builds the idIndex (memoised on schema) and threads
  it through shouldDisplay → evaluateDependencies.

Backwards compatible: callers that don't pass idIndex see identical
behavior. Consumers whose backend guarantees globally-unique field ids
(e.g., flat-storage schemas) can now use id-keyed dependencies, which
stay valid across structural moves (no parent path to update).

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 22, 2026

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2aeb3416-4b48-4985-a03d-2cbdadd684bb

📥 Commits

Reviewing files that changed from the base of the PR and between e0b02a0 and 827b418.

📒 Files selected for processing (2)
  • src/components/settings/settings-context.tsx
  • src/components/settings/settings-formatter.ts

📝 Walkthrough

Walkthrough

The PR enhances dependency resolution in the settings form system by introducing a fallback mechanism. A new buildIdIndex helper precomputes field id-to-dependency-key mappings from the schema, which evaluateDependencies uses to resolve undefined dependency keys. The settings context memoizes this index and passes it during field visibility evaluation.

Changes

Dependency Resolution Enhancement

Layer / File(s) Summary
ID-to-dependency-key resolver
src/components/settings/settings-formatter.ts
buildIdIndex walks the schema and builds an iddependency_key lookup. evaluateDependencies is updated to accept an optional idIndex parameter and, when a dependency key is undefined, uses the index to resolve the key before re-reading the value.
Context wiring
src/components/settings/settings-context.tsx
Import buildIdIndex and create a memoized idIndex from the schema. The shouldDisplay callback passes this index to evaluateDependencies to enable fallback resolution during field visibility evaluation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

  • getdokan/plugin-ui#90: Implements the same buildIdIndex + evaluateDependencies id-fallback pattern with identical wiring in context and formatter modules.

Poem

A fuzzy-eared fix for fields that hide—
When keys go missing, we peek aside,
An index built from the schema's core,
Finds the dependency, opens the door! 🐰✨

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch settings/field-id-deps

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint skipped: no ESLint configuration detected in root package.json. To enable, add eslint to devDependencies.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@kzamanbd kzamanbd merged commit e4894b4 into main May 22, 2026
3 checks passed
@kzamanbd kzamanbd deleted the settings/field-id-deps branch May 22, 2026 04:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants