From a0054052de182fe195de894eec7cd1b7f867b939 Mon Sep 17 00:00:00 2001 From: Guy Sartorelli Date: Tue, 19 Dec 2023 12:58:15 +1300 Subject: [PATCH 1/2] DOC Document lazy loading --- .../02_CMS_Architecture.md | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md b/en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md index 0f8c49068..9e0459e12 100644 --- a/en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md +++ b/en/02_Developer_Guides/15_Customising_the_Admin_Interface/02_CMS_Architecture.md @@ -774,6 +774,38 @@ The URL endpoints `{$AdminURL}mytabs/tab1` and `{$AdminURL}mytabs/tab2` should return HTML fragments suitable for inserting into the content area, through the `PjaxResponseNegotiator` class (see above). +### Lazy loading fields on tab activation + +When a tab is not lazy loaded via ajax, it might still be necessary to +delay some work (for example when doing HTTP requests) until the tab is activated. This is how, for example, the +[`GridFieldLazyLoader`](api:SilverStripe\Forms\GridField\GridFieldLazyLoader) works. + +In order to open up the same kind of features to other fields, a custom event is fired on all nodes with the `lazy-loadable` class inside the activated tab panel. +They will receive a `lazyload` event that can be listened to in the following way (you will have to implement your own logic for "loading" the content): + +```js +jQuery('input.myfield.lazy-loadable').entwine({ + // Use onmatch so we apply the event handler as soon as the element enters the DOM + onmatch(e) { + // Use the one() function so the lazyload only happens once for this field + this.one('lazyload', () => { + // Some init code here + }); + }, +}); +``` + +[info] +The `myfield` CSS class isn't strictly necessary here (nor is the input for that matter) - it's just being used so we have a more specific selector. That way we know our JavaScript code will only trigger for the relevant element, and not for every lazy-loadable element in the DOM. +[/info] + +If you apply the `myfield` and `lazy-loadable` CSS classes to some form field on a tab other than main, then when you swap to the tab containing that field it will trigger the lazyload event for that element. + +```php +use SilverStripe\Forms\TextField; +$fields->addFieldToTab('Root.AnyTab', TextField::create('MyField')->addExtraClass('myfield lazy-loadable')); +``` + ## Related - [Howto: Extend the CMS Interface](/developer_guides/customising_the_admin_interface/how_tos/extend_cms_interface) From 3136033fb9920698fd7048fd050e0ce0131f1f57 Mon Sep 17 00:00:00 2001 From: Steve Boyd Date: Fri, 26 Jan 2024 12:36:14 +1300 Subject: [PATCH 2/2] DOC Add description for type/other label and clarify affects labels --- en/05_Contributing/00_Issues_and_Bugs.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/en/05_Contributing/00_Issues_and_Bugs.md b/en/05_Contributing/00_Issues_and_Bugs.md index b4e2ef2c6..a49a2dcc5 100644 --- a/en/05_Contributing/00_Issues_and_Bugs.md +++ b/en/05_Contributing/00_Issues_and_Bugs.md @@ -91,7 +91,7 @@ The current GitHub labels are grouped into five sections: 1. *Impact* - What impact does this issue have, does it break a feature completely, is it just a side effect or is it trivial and not a big problem (but a bit annoying), etc. Impact is evaluated in the context of the CMS as a whole, rather than against the individual module the issue is raised on. 1. *Complexity* - What level of technical proficiency is required to address this issue? 1. *Type* - The type of solution required to address this issue -1. *Affects* - The release line this issue is relevant to +1. *Affects* - The major release line this issue is relevant to - for instance `silverstripe/admin 2.0.0` is on the CMS 5 major release line, so use `affects/v5`. Do not add this label for unreleased major release lines, instead use `type/api-break`. 1. *RFC* - The issue is a request-for-comment | Label | Purpose | @@ -109,6 +109,7 @@ The current GitHub labels are grouped into five sections: | type/ux | Impact on the CMS user interface | | type/docs | A docs change | | type/userhelp | A userhelp documentation change | +| type/other | Any issue that does not is not covered by another type label e.g. general maintainence | | affects/* | Issue has been observed on a specific CMS release line | | rfc/draft | [RFC](/project_governance/request_for_comment) under discussion | | rfc/accepted | [RFC](/project_governance/request_for_comment) where agreement has been reached |