Support custom core fields via config - #419
Conversation
Add a new config option 'coreFields' (default null) to allow apps to specify core field classes. Bolt facade now reads zeus-bolt.coreFields: if an array is provided it builds the core field list via Collectors::buildClasses, otherwise it falls back to the package default classes. Also prevent auto-including Bolt Pro fields when custom coreFields are set. Made Collectors::buildClasses public so it can be invoked from the facade. Preserves existing behavior when coreFields is not configured.
PR Summary
|
|
i like the idea, clean and direct. |
Introduce Bolt::allFields() to aggregate and cache all field definitions (core, app, configured coreFields array, and Bolt Pro fields when available) under the 'bolt.allFields' cache key for 1 month (cleared in local). Merge and sort collected fields by their 'sort' value. Update Filament field select usage in Fields trait: expand closures for readability, add getOptionLabelUsing to resolve labels from allFields(), and adjust formatting/imports. Clarify config comment for 'coreFields' behavior (array to override, null to auto-discover).
Add unit tests for Bolt field discovery and configuration. Tests cover Bolt::allFields and Bolt::availableFields behaviors including auto-discovery, merging configured coreFields, duplicate avoidance, empty arrays, and validation of returned field array keys. Introduces a DummyField test stub implementing FieldsContract to simulate a custom field; tests flush cache and collect auto-discovered classes for assertions.
Adds a new "Core Fields" section to docs/getting-started/configuration.md that documents the coreFields configuration option. Explains that core fields are auto-discovered by default (coreFields => null) and shows how to override discovery by providing an array of specific field class names. Includes examples and notes that custom fields can be included alongside core fields.
|
Since its only used at filament layer, wouldn't it better to move this config into the plugin registration phase ? , like the following: ->plugins([
BoltPlugin::make()
->formFileds([...])
])This way will have the following advantages: Contextual Flexibility: If a user has multiple panels (e.g., Admin and App), they might want different settings for each. A Plugin class allows them to configure each instance uniquely. Type Safety & IDE Support: Users get immediate autocomplete for our methods. Dynamic Logic: If the configuration depends on other panel settings or runtime state, the Plugin class is more powerful. Whats your opinion on this @atmonshi ? |
|
Check #427 |
|
@Abdulmajeed-Jamaan close this in favor of #427 ? |
Changes `coreFields` behavior so an array now defines the complete set of available fields (instead of merging with discovered fields), while `null` keeps auto-discovery for Bolt, app, and Pro fields. The field type picker now defaults to the first sorted available field, docs/config comments were updated to clarify cache invalidation (`bolt.fields` and `bolt.allFields`) and ordering rules, and tests were replaced with end-to-end coverage of the new picker/config behavior.
|
Handled default field mentioned here as well |
2 participants
Support for #413 .
Alternative solution for #414 , Add a new config option 'coreFields' (default null) to allow apps to specify core field classes instead of loading all in specific folder path.
Remaining Tasks:
need your feedback on this @atmonshi