frint: We shouldn't trust Child Apps in Region — anything could happen ©

This responsibility cannot be delegated to the app developer. It has to be contained under the core system.

In general, browsers act mostly in the same way when it comes to <script src="..."></script> tags.

<script src="vendors.js"></script>
<script src="a.js"></script>
<script src="b.js"></script>

Say that both a.js and b.js, depend on vendors.js (classical type of structure here)…

If a.js has an error, a.js execution stops, but doesn’t block from b.js to run. Vice-versa for b.js

But if by any case, the error happens at the top (vendors.js) because an app is trying to use a method available on the vendors that is not being properly used AND the errors not properly handled, we have a broken page.

Although that should be properly monitored, logged and/or notified to the FB app developer, it should not at any time be a blocker for the whole page. Breaking normal functionality because of a misuse of the FB app dev, it is a big no-no.

@froskie, I think the idea is that we should both

• surround the registerApp call with a try-catch to catch any errors during app registration.
• implement componentDidCatch to handle any rendering errors.

The work already started in rwd to do this automatically for every app: https://bitbucket.org/xivart/rwd_cheaptickets_nl/pull-requests/5680/mp-223-fb-bundler-handle-errors-from-fb/diff With that in place we don’t have to do anything in the actual apps, and we’ll get a default implementation of componentDidCatch generated by default, which simply hides the app if its rendering throws an error. @fahad19 what’s left to be done in that PR?

@markvincze: thanks for explaining so nicely, Mark!

As soon as the acceptance builds are done, and e2e tests are performed, the PR can be merged.

I would suggest doing further (unit/integration) testing-level improvements in our extracted bundler service in future.

I have already given a list of affiliates to @viacheslaff to deploy to acceptance. Best to deploy affiliates which have active Apps as seen in AppSelector UI (in production).

I don’t think Region should be responsible for error handling and specifically for rendering custom UI errors. Nevertheless website should protect itself from crashing caused by child apps. It can be done by creating an ErrorBoundary component, like @asci suggested. It can also be a HOC. Either of those options can be reused for consistent child app error handling in the website. This component can be website specific and I don’t think it should be part of frint-react.

I fully agree with @fahad19 on this. This is custom setup at least and should not belong in the framework and for lack of a stronger argument, i don’t see reasons why to provide an option for error handling when there is one simple and viable option to do it with react already.

We have to keep in mind this has a long-term API impact, so i’d rather handle this error at bundler level or anything outta the framework for that matter.

@maximuk: what’s the reason of not throwing the error using your custom ErrorClass from inside the componentDidCatch lifecycle hook of your React component?

Possible solution 3

Implement componentDidCatch wrapper component in website with some sending alerts and wrap all the regions, see ErrorBoundarycomponent here