Being a minor version release, JET 4.2.0 is mostly about bug fixes and additive enhancements to the component set (see here for a good roundup from John Brock on the JET team). For those of you writing Custom JET Components (CCA) the immediate impact is minimal but there are some changes that you may need to start making to your components if you are a more advanced user.
By far the biggest change in this release is some fine tuning of the component lifecycle, Some of you may be using the existing attached() and detached() (or older dispose()) lifecycle methods in your components and if so you need to pay careful attention here. The attached() and detached() methods are generally used as places to manage event listeners associated with a component, for example, if your component needs to register a change listener on itself or a document level listener, then the attached() method is (generally*) the correct stage in the lifecycle to carry that kind of work out, as the DOM node for the component will actually exist at that point in time and will be fully upgraded to the state of being a real component. Likewise you may clean up after yourself in detached().
However, in older versions of JET we have a subtle inconsistency, the attached() method is only called the very first time that a component instance is first inserted into the DOM whereas the detached() method would be called every time the component is removed. So if you have a component that is created and then (for example) moved, attached() would be called once but detached() could be called multiple times. If you are relying on these methods to manage listeners as outlines above you could find yourself broken.
To address this, and generally make things more logical we've created a balanced pair of lifecycle methods connected and disconnected. The disconnected() method is identical to the detached() method in that it fires every time the component element is removed from the DOM. The connected() method, however, now mirrors that behaviour and fires every time the element is connected to the DOM, not just the first time. So this means that you now have a balanced pair of callbacks where you can register and then remove event listeners safely without ever getting out of sync.
If you make any change at all in response to this upgrade then renaming your attached() functions to connected() would be the one to make. Oh and of course if you realize now that you have been creating listeners without cleaning them up, then perhaps you should implement a matching disconnected() function to do so?
So functionally that's the only change to worry about, however, if you take a peek at the documentation for composite in the JSDocs you'll see that the amount of metadata associated with the various parts of the component defintion (the component.json file) has increased significantly. What we have started to do here is to enrich the basic component API with additional descriptive metadata. You will see for example, that a property can now encode a minimum and maximum value if it is a number or a date and so on. This information can be provided for two purposes, firstly of course it improves the quality of your API, the more you describe, the less room for misinterpretation. Secondly, this information is of course machine readable, and so design time environments such as Visual Builder Cloud Service can read the configuration and generate Property Inspectors and other design time elements that will use this information to provide a much improved user experience when working with custom components. Custom JET Components are now the component model for VBCS going forward, replacing the custom approach that was formally used within that product and we anticipate that by far the majority of Custom Jet Component usage will actually be through that platform rather than in hand-coded JET applications.
I'll be writing much more on Custom Jet Components and VBCS in a future article, but for now, have a look at the new metadata and take advantage of it to enhance your component APIs.
Just to wrap up, JET 4.2.0 is out on schedule and the train never stops, so as a component developer you need to keep on top of the game and not accumulate code that might cause you problems in the future (the deprecated lifecycle methods being a case in point). So put aside the time to stay on top of the curve rather than trailing behind and have a look at scheduling core upgrades such as replacing the use of Knockout data-bind with the equivalent <oj-bind-*> tags, and <oj-slot> with <oj-bind-slot>. If you look back on this blog series, you'll see that I've been cleaning up my example code as well so there's no excuse!
Also check back to see if you are using the now obsolete pending and ready events, these should be replaced by lifecycle methods in the case of the component listening to itself and if you are using them from outside of the component to check when it's ready to go then use the busyContext instead.
If you've just arrived at JET composite components and would like to learn more, then you can access the whole series of articles on the topic from the Composite Component Architecture Learning Path
* The one exception being when you want to register a listener against an element which is relying on a generated sub-id that won't be resolved until the bindingsApplied() phase is complete