ZupIT/beagle

Reusable custom component in JSON level

Closed this issue · 3 comments

Use case

Use JSON only to create custom component.
Provide a mechanism to create our own custom component through JSON level only

  • Increase reusability on the JSON level
  • Avoid native construction
  • Easily share component
  • Avoid typing the same thing again & again.

One of the use cases include construct JSON only level of item and reuse in other place of the screen.

Proposal

  • New section to define reusable functions:
"snippet": {
     "name": "snippet:foo",
    "parameters": { // or context?
          "number" : "int",
          "name": "string"
    },
    "body": {
        "_beagleComponent_": "beagle:container",
        "children": [
            {
                "_beagleComponent_": "beagle:image",
                "path": {
                    "_beagleImagePath_": "remote",
                    "url": "https://bar.com/@{background.@{int}.png}".  
                },
                {
                     "_beagleComponent_": "beagle:text",
                     "text": "I can be reused and reused again! @{name}",
                }
            }
        ]
    }
}

and in any place within the same page, we can use as if we create a custom component in native.

    {
        "_beagleComponet_" : "snippet:foo"
        "number": "1",
        "name": "first one"
    },
    //... 
     {
        "_beagleComponet_" : "snippet:foo"
        "number": "2",
        "name": "second one"
    },

Hello @brianchu

I see this as an interesting idea for 2 use cases:

  1. Someone writing the JSON by themselves, without a proper backend (not recommended).
  2. For reducing the size of the JSON.

If you use Kotlin for the backend application, you can use a Composed Component to create these reusable components. The documentation talks about this here.

The same can be done if you're using the backend for Typescript. The documentation talks about it here.

Do you see any use case other than the two I mentioned? If not, I think the main advantage of this would for reducing the size of the overall JSON, since we don't recommend writing the json without a proper backend language.

Reducing the size of the JSON is a valid reason for a feature, but I'm not sure if the size of the current JSON is an actual problem.

Is the JSON size becoming a problem in your application?

Hi, I'm passing here just to let you know that the Beagle team is taking some vacation time.

We'll take 2 weeks off and be back at Feb 06. Feel free to keep commenting in this issue and we'll address it as soon as we're back.

Closing this due to inactivity.