Closed pgross41 closed 4 years ago
Should the correct fix here be to disable XFC from logging to console and instead allow a custom logger to be passed in? What specific event is XFC writing when something is added to the DOM? Its also possible XFC should be less chatty on the console.
Should the correct fix here be to disable XFC from logging to console and instead allow a custom logger to be passed in? What specific event is XFC writing when something is added to the DOM? Its also possible XFC should be less chatty on the console.
There are likely better options than this PR. In the issue I noted "It seems like this is meant to be called only on a resize, so maybe it needs to be smarter about detecting if the event is actually a resize or not." Here is everything being output:
Another option is don't write out if it's a duplicate resize message.
If we could pass in a dummy logger it would resolve the issue e.g. (message) => null
. An option to disable XFC output entirely would also resolve the issue.
This is not the proper solution to the problem, will provide details on https://github.com/cerner/xfc/issues/45
Summary
Add ability for other code (e.g. F-Twelve) to exclude themselves from XFC's requestResize function https://github.com/cerner/xfc/issues/45.
Example: Currently an endless loop occurs when using F-Twelve and XFC:
console.log
is called.console.log
every time anything is written to the DOM.This PR provides an exclusion class that F-Twelve can implement which will allow it to not trigger XFC.
Additional Details
It is common for an MPage developer to use F-Twelve as well as cerner-smart-embeddable-lib, they should able to use them both at the same time.