Conditional field: suggest candidates based on another field's value (Domain → Type)

[mdelobelle]

Reposted to Q&A from the welcome thread so it's easier to find — original question by @Azmoinal.

Can a link field's suggestions depend on the value of another field in the same note?

Example: a Domain field and a Type field that depends on it. If Domain is earth, the Type picker should only suggest notes whose Domain is also earth — ideally with a single base file rather than one base per possible Domain value.

Is this.Domain the right way to reference the edited note's value when Fileclass evaluates the bound base?

[mdelobelle]

Not a dumb question at all, and you already nailed the key part: this works. 🎉

When Fileclass builds the candidate list for a link field, it runs the bound Base view with the note you're editing as the view's context — so inside the view's filters/formulas this resolves to that note, including its frontmatter properties via this.<PropertyName> (not just this.file). One base is enough; no need to spam one base per Domain value.

For your Domain → Type case, assuming each Type note carries a Domain property, add a formula + a view to the base bound to the Type field:

formulas:
  # true when this candidate's Domain equals the edited note's Domain
  sameDomain: Domain.isTruthy() && this.Domain.isTruthy() && (Domain == this.Domain)
views:
  - type: table
    name: Types for this domain
    filters:
      and:
        - formula.sameDomain == true

Then point the Type field at that view (baseFile + viewName). Two references to keep straight:

• bare Domain = each candidate row's own Domain,
• this.Domain = the Domain of the note you're editing.

The example compares Domain as a plain value (a word like earth), matching your description. If your Domain is instead stored as a link ([[Earth]]), compare basenames: file(Domain).basename == file(this.Domain).basename.

Two gotchas worth knowing:

1. Set Domain first. The picker reads it from the note's frontmatter, so it must be saved before you open the Type picker.
2. The dependency isn't reactive. If you later change Domain, an already-chosen Type value is not revalidated or cleared — you'd re-pick it yourself.

The .isTruthy() guards aren't decorative: on an empty value a bare comparison can reduce to null == null → true and surface every value-less candidate before Domain is set — so keep at least one guard.

I just documented this whole pattern here: https://mdelobelle.github.io/fileclass/fields/#conditional-candidates-dependent-fields ("Conditional candidates"). Give it a try and let me know how it goes!

[mdelobelle]

Follow-up: I've opened a feature request to make this a guided option in the field settings editor — pick the source field and Fileclass would forge the formula + view for you, no hand-written YAML — so the manual pattern above becomes the "under the hood" version rather than something you have to write yourself.

Tracking it here: #19 👍 (thanks @Azmoinal — your question is what prompted it)

[Azmoinal]

Wow. Thanks a lot for the detailed answer and to plan to include a guided option. I'll try to apply what you suggested in the documentation and I'll let you know. Thank you again for your help!

[Azmoinal]

Hi @mdelobelle, I've another doubt about the base that I'm using to return the list of values after the filtering.
I tried to apply an order to the returned items in order to have them in alphabetical orders but it seems that the list of items suggested by the menu is not related to the one applied in the base file. Is it an expected behaviour?

I've a case when the list is quite long so I would like to have list item in an ordered way to select them quickly. The same behaviour apply to Select and Multi.