Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-129529

Implement the Forms and DE data representation mechanism

Details

    Description

      Well, currently DataLayoutBuilder's responsibility has been split into two, previously dealing with:

      • Instantiate the FormBuilder and LayoutProvider application in Metal.js
      • Add methods to convert the data structure from Forms to DE and DE to Forms

      Now he just deals with instantiating the FormBuilder and LayoutProvider and the structure conversion is in charge of the DataConverter file with its methods.

      This is still not enough for us to migrate the Data Engine to be full React.js and remove Metal.js from there because we still need to live with both types of data structure.

      The reducers of the current foundation that were the old methods of LayoutProvider only know how to talk in the data structure of Forms and we want to use them as part of the foundation of DE. Currently, FormProvider is agnostic of structure, reducer, and action but it will be the SSOT for application data. Some parts of the DE codebase only understand the structure of the Data Engine, MultiPanelSidebar, and its dependent components, but the part of the new foundation in React, only in Forms.

      Once the App Builder adopts the composition instead of taglib, using the main components of the DE core to compose the Form Builder application. There is a problem that they don't need to know that internally the reducers or FormProvider stores the data in the Forms structure or they have to call Data Converters to do the service and have to write their own reducers in the Forms structure. We don't want applications outside the DE to know this information, we want to isolate the core level.

      The main idea is to smooth out these two types of structures within the application without people calling the Data Converter directly.

      The purpose of this ticket is to develop a more organized and smooth way to implicitly leave the existence of these two structures so that the new DE application can slowly migrate the reducers, components to talk in the DE structure and make the two structures coexist in the same application.

      Goal

      • MultiPanelSidebar and dependent components must continue to consume data in the DE structure
      • It must be possible to build reducers in the DE structure and trigger actions as well.
      • Consume data in the DE and Forms structure without calling Data Converter
      • App Builder must not know the structure of the DE when using the new foundation components

      Proposal

      With all this in mind, the proposal focuses on developing a solution on top of FormProvider and useFormState.

      • The developer can tell useFormState which representation of the data he wants to view (DE or Forms). Always encouraging you to use the DE structure.
      • Use data representation instead of converting data to decrease performance problems (Always try to use a reference instead of allocating new objects)
      • Use simple Schema to handle data representation and allow lazy conversion and better use of memoization
      • The developer must be able to write a new reducer with the DE structure and dispatch with the DE structure
      • Allows for a slow migration so that all the components just talk in the DE structure

      FormProvider only stores the raw data (in this case the Forms structure) and useFormState offers two outputs of the data, Forms or DE, Forms by default and DE being configured in the function call, the schema is also used to tell which object should be created the representation to not have to create of all the data and cause performance problems in the renderings of the components.

      The new reducers by default receive the status in the structure of the DE but in the end, it is saved in the structure of the Forms (This will change in the future when all base reducers use the DE structure).

      This solution centralizes the conversion of data in just one place, other components do not know that there are two representations, it allows the components to be migrated slowly to the DE structure as well as the reducers, the customers of these components will not know about the Forms structure.

      The data representation will be smoother and we will have less performance problems compared to using the Data Converter in the places you need and we don't need to migrate all the reducers that are copies of the LayoutProvider to work on the Data Engine's data structure now.

      Implementation plan

      The idea is not to build everything now on this ticket but to prepare the FormProvider and useFormState for that, just build the skeletons and patterns and allow the schemas and the representation of the data to be added as we work on AB and DE.

      • Implement Schema for data representation
      • Add flag to consume the data in the DE or Forms structure in useFormState
      • Implement the possibility to create and save reducers with the DE structure

      Attachments

        Issue Links

          Activity

            People

              brian.chan Brian Chan
              matuzalem.teles Matuzalém Teles
              Matuzalém Teles Matuzalém Teles
              Kiyoshi Lee Kiyoshi Lee
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Packages

                  Version Package
                  7.4.0 CE GA1 DXP 7,4
                  7.4.13 DXP GA1
                  Master