Uploaded image for project: 'Hippo CMS'
  1. Hippo CMS
  2. CMS-14373

Simplify navapp-communication API interface

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • None
    • 14.5.0
    • None
    • None
    • 0.5
    • Pulsar 252 -DocTypes & Gateway

    Description

      Currently the Parent and Child api's are a mix of promise and non-promise returns, now that async await syntax is available we should just always return a promise. This would merge the ParentApi and ParentPromisedApi interfaces into 1 (same for ChildApi and ChildPromisedApi) and make the API more clear and predictable.

      tldr; Instead of making ParentApi methods optional in the typescript interface, version the ParentApi interface when there are actual breaking changes somewhere in the future.

      Long version:
      Also all interface methods for the ParentApi and ChildApi are potentially undefined. This makes sense for Child apps as they might or might not implement certain hooks.
      However for the ParentApi we know that the navapp is the only app implementing it, and that all methods are in fact implemented and available right now for all client apps currently hosted within the navapp. Making them optional in the typescript interface makes coding with the API a lot harder as all methods can potentially be undefined and all kinds of guards against that need to be in place.

      There could be 2 situations where a ParentApi method could be unexpectedly undefined :

      • The case where a navapp (brxm) is hosting a client app (brsm) that has a newer version of the communication lib than the navapp.
        Solution: Package separate interfaces for the ParentApi per backwards incompatible version so the client app can determine implementation based on the version communicated by the parent app.
      • The case where the navapp (brxm) is using a com lib version newer than its client app (brsm).
        Solution: We can easily avoid this situation by making sure that client apps update their nav com lib and release before the parent app, ending us up in situation 1.

      Aside from the above the Parent app is always the Navapp, and even if there is a proxy layer such as Wicket in the cms, it should forward all method calls to the Navapp anyway.

      Attachments

        Activity

          People

            Unassigned Unassigned
            jdegooijer Joeri de Gooijer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: