Feeding backend configs to React Components

Tags: #<Tag:0x00007f01bf186cb8> #<Tag:0x00007f01bf186998>

Hi @mogoodrich,

Let me present a simple use case to ask my question. @andu033 is integrating Attachments widgets into React Components as part of GSoC 2019. When coming to the thumbnail component we need to know in which format to display the date-time stamp. Attachments (the module) has been providing this to its framing GSP pages through a config passed on from the controller (here and here). This was simple because everything was “attachments”.

Now in React Components, I understand that we want components to be standalone, however they might need to share configs for the sake of UI consistency. Such as how to format dates for instance.

I saw this :wink:

How do we avoid this for instance? Should the store maintain an expandable configuration, or what would be your take on this?

1 Like

@mksd my quick thought would be that a “dateFormat” prop is added to the “CustomDatePicker” element, and it passes that on the DateDisplay.

That prop would be mandatory, but would have a default value of “dd MMM yyyy”.

Longer term, we may want to store a default date format in the store and so the precedent would be:

  1. Value passed in as dateFormat prop, if present
  2. Default date format from the store
  3. “dd MMM yyyy”

But now as I’m rereading you question… does this answer it, or is it really a bigger question of how to pass configuration that is currently specified server-side to a React Components front-end?

Take care, Mark

Thanks @mogoodrich, yes it’s rather the latter about this:

Default date format from the store

This suggests that the store would be pre-filled with defaults, and those have to be managed somewhere. It doesn’t have to come from the backend though, there could be some sort of front-end config for that (a bit like Bahmni Apps is being configured).

So there’s already a “metadata” section of the store that has been set up… seems natural for it to be stored there, perhaps as a “config” subsection? Or maybe we want config separate from metadata?

Note that there’s already means to fetch and cache global properties:

Take care, Mark