• Type: Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:


      Creating this in reference to discussion here:

      That is specifically about what we think is a harmless bug (where we unmount React components too zealously when any portlet is destroyed), but we think the solution ties in with something we wanted to do anyway in the name of having better ergonomics for defining the data to be passed to a React app and mounting it from JSP files.

      Here's the context from that discussion:

      we think that in practice we're unlikely to run any problems with this, for now, because we don't have multiple React portlets on any page currently, and even if we did, we tend to destroy all portlets on navigation, with few exceptions. So blowing away all the rendered components any time a portlet is destroyed may just be fine.

      That's not an argument for not making this more robust; it's just a statement about how urgently we should pursue a fix — for example, if we thought it actually would cause bugs soon, the quickest thing to do would be to just pass in the portlet ID here and use that to do a targeted unmount. But given that we don't think we'll actually suffer any bugs because of this, my preference is to pursue a deeper/better fix, which will be to provide a <react-render> (or similar) tag to replace all these usages of <aui-script require="..."> that we're currently using to mount these React apps, and which would abstract away all this business of propagating portlet namespaces, IDs etc (analagous to what <liferay-frontend:component /> does). Then it would be trivial for us to do a targeted destroy automatically on behalf of the developer.

      We need to be mindful about the cost of round-tripping data from Java (where we have ready access to the data model)  → JSP (where we are printing HTML) → Tag (where we end up having to serialize the data all over again in order to print it), but we can cross that bridge when we come to it.


          Issue Links



              • Assignee:
       SE Support
                greg.hurrell Greg Hurrell
                Recent user:
                Greg Hurrell
                Participants of an Issue:
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created:


                  Version Package