Closed ilinkuo closed 3 years ago
We can put @deprecated
on both CONTAINER_WIDTH_CHANGE
and APP_WIDTH_CHANGE
in favor of the _RESIZE
variants. The CONTAINER_WIDTH_CHANGE
is automatically fired when the browser is resized so for backwards compatibility both CONTAINER_WIDTH_CHANGE
and CONTAINER_RESIZE
will need to be fired. APP_WIDTH_CHANGE
is to be fired by the container itself, so no change would be needed inside of F2 - the container would need to fire the new APP_RESIZE
as well.
I need to give some more thought to the implications of _RESIZED
and expanding the use of updateHeight()
(currently this method only applies to secure apps to update the height of the containing iframe) and potentially adding updateWidth()
.
It seems to me that the App should notify the Container of any dimension changes regardless of whether or not it's loaded securely? That would remove the need for ugly conditional code such as
if (appConfig.isSecure){
updateHeight(200);
// ...
} else { /* Do something else */}
I think there's also a decision to be made as to whether these communications should be made via events or direct function calls.
Not urgent.
Currently, F2.Constants.Events has four events --
APP_SYMBOL_CHANGE, APP_WIDTH_CHANGE, CONTAINER_SYMBOL_CHANGE, CONTAINER_WIDTH_CHANGE
. I recommend thatAPP_WIDTH_CHANGE
andCONTAINER_WIDTH_CHANGE
be dropped in favor ofAPP_RESIZE, APP_RESIZED
andCONTAINER_RESIZE
. Where the_RESIZE
event has a value of the formReasons: Height and width changes should be handled together, not as two separate events.
APP_RESIZE
is a command event from the Container to the App telling it to resize itself, whileAPP_RESIZED
is a notification from the App to the Container. TheAPP_RESIZED
event can be in response to anAPP_RESIZE
command from the Container, or due to other factors not controlled by the Container. (An alternative toAPP_RESIZED
is to add anupdateWidth()
method to F2 in addition to the already existingupdateHeight()
).