Templates need to verify if objects are existing or are in required type for processing

[speedupmate]

https://github.com/shipperhq/module-shipper/blob/19375c1a012e5d94ca80e5e36c48141adef5a506/src/view/frontend/web/template/billing-address/details.html#L14

https://github.com/shipperhq/module-shipper/blob/19375c1a012e5d94ca80e5e36c48141adef5a506/src/view/frontend/web/template/shipping-address/address-renderer/default.html#L14

https://github.com/shipperhq/module-shipper/blob/19375c1a012e5d94ca80e5e36c48141adef5a506/src/view/frontend/web/template/shipping-information/address-renderer/default.html#L23

https://github.com/shipperhq/module-shipper/blob/19375c1a012e5d94ca80e5e36c48141adef5a506/src/view/frontend/web/template/shipping-information/address-renderer/default.html#L15

https://github.com/shipperhq/module-shipper/blob/19375c1a012e5d94ca80e5e36c48141adef5a506/src/view/frontend/web/template/shipping-information/address-renderer/default.html#L28

also see core issue in just released 2.4.3 https://github.com/magento/magento2/issues/33826

The issue is that whenever those templates are bound to their module context the data in those objects or the objects might not jet exist: undefined, null, string, object/array (empty, full, partial) dependant on script load order/speed or their inclusion changed by layout, templates (earlier than you have tested, later etc) . Application state is not under your control and you can't depend on it and take variable existence as granted.

when faced resulting fatal error on knockoutjs level that stops all further script loading and rendering , simply put you broke the checkout (default or any customised version of it)

[wsadasmit]

Hi @speedupmate, thanks for raising this, I've scheduled it for review.

[speedupmate]

just a friendly reminder , over a year has passed, this is still biting your customers on every installation

[wsajosh]

Thanks @speedupmate . I've just released a new version that addresses this, thanks for raising the issue