Enabling Custom written components along with the UIDL

[JayaKrishnaNamburu]

Proposal

To support external code components in the project-generation phase. Currently the project/component generators can understand components from local and external with the dependency attribute. But one limitation right now is.

• The reference with dependency type local should be from the UIDL itself.
• The reference with dependency type package should be any external one. Like a npm dependency or a module loaded from external cdn etc.

Problem

Let's say i have a couple of components with some complex logics, that i want to use them in the process of the project generation. But defining those components in UIDL again is not a reliable solution. What if i have a custom-component which is already completely written and i just want to use it by dropping it's code.

Writing the component again in UIIDL is not a better Developer Experience or User Experience. And we don't like to inject everything in the UIDL in strings format to use them to generate at the build time.

Solution

The one good way to handle this scenario is to enable project plugins. We have component plugins but not project plugins.

The component plugins, takes in UIDL and then generates chunks which are AST based and not string based.

Process

We will enable a new method called addPlugin which looks like

const generator = createProjectGenerator({
    components: {
      generator: reactComponentGenerator,
      path: ['src', 'components'],
    },
    pages: {
      generator: reactPagesGenerator,
      path: ['src', 'views'],
    },
   .....
  })

  return generator
}

generator.addPlugin(customProjectContentPlugin)

And the customProjectContentPlugin inherits inMemoryFilesMap which was introduced in v0.13, and project UIDL and few other things.

So it can look something like

const customProjectContentPlugin = ({ inMemoryFileMap, uidl, rootFolder, dependencies }) => {
  inMemoryFileMap.set('CustomDatePicker', {
    rootFolder,
    ['src', 'components'],
    [{
      name: CustomComponent,
      type: FILETYPE.JS,
      content: `
      class Welcome extends React.Component {
        render() {
          return <h1>Hello, {this.props.name}</h1>;
        }
      }
      `
    }]
  })
}

At the end of generating project, all these plugins are executed and thus we can inject the files into the final project.
While generating the UIDL, we can refer to these as

       "elementType": "PersonSpotlight",
        "semanticType": "CustomComponent",
         "dependency": {
              "type": "local",
               "path": "./custom-component"
          },

[JayaKrishnaNamburu]

The proposal is not mainly targeted on supporting custom-components. They can do basically anything, since we get access to all the files before generated into project.

We can inject few, remove few or even manipulate the whole template files. Since we will have access to the template too. So, we don't end up filling @teleporthq/teleport-project-generator more

[paulbrie]

@JayaKrishnaNamburu, this looks awesome!

From my understanding, the proposal you make is proposing to use two sources of information in order to generate the code: (a) UIDL, (b) custom code:

I wonder if we could consider the benefits of storing the reference to the custom code in the UIDL itself:

I think that the benefits of the second approach are:

• enabling cross-platform communication
• using one single source of truth
• enabling custom code to execute in the renderer (during the visual development phase, as in our Playground)
• cross-validation of components used

One of the disadvantages of that approach is that the UIDL size can grow quite a lot, but we could mitigate this aspect with both the use of our existing imports mechanism and various compression techniques.

[JayaKrishnaNamburu]

Yes i agree, by making the custom code available in the UIDL. It can helps in interoperability. We can just use UIDL to communicate between two different systems, and they still get to know about the custom written code.

Now, we have two things. If we should load everything in the UIDL, or refer
it from the remote URL and load them at code generation time.

Loading everything in UIDL

Pros

• No runtime issues like, to make some API calls and then load components, and to files and then generating projects.

Cons

• UIDL's won't be user friendly to scan through, on a high level for users.
• Size of UIDL's will be definitely big, if the users have more than one component.

Using remote references in UIDL and loading at project generation time.

These are just opposite for the above approach.

---

I would say, let us support both and so we can bring in the remote loading functionality via some project plugins. So, we have two plugins at project level

• Takes everything from UIDL at build time and generate the component files in the build.
• Loads from remote reference at build time and then load them in build.

In the above two approaches, we need to introduce a new attribute in UIDL like type: custom and content: ... as remote or just the component code etc.

Maintaining a custom registry

Here is a small POC, that i did a year back. Maintaining a custom registry --> https://github.com/JayaKrishnaNamburu/teleport-registry

Every component that users write in their respective projects are available as individual packages in a custom registry. Then we don't need to make any changes to the existing solution. The registry acts as CDN and serves the components dynamically. The end solution can be a hybrid work of https://github.com/JayaKrishnaNamburu/teleport-registry + https://github.com/teleporthq/teleport-registry-packer

Pros

• We don't need to change anything in the project generation pipeline
• We already know the solution works. Just need the infrastructure for the backend.
• We don't need to introduce any new attributes, it's just a package manager kind solution alternative to npm.
• We can still write some project plugins and load them at code-generation time. To load these and add as static files in build at build time. So, no need to reply on CDN or on us at runtimes.

Common issues to address

• Dependencies management, from hand written code, we need to scan the imports and then inject them into package.json. If the user is using any third party dependencies. So, we need to think of a approach, if we are going to scan and extract the imports or just let users to define from the UI where they are going to define the custom code.

cc @Utwo @paulbrie

[paulbrie]

I really like the idea of offering both options for Custom Components (stored in UIDL, or injected during build-time). Let's move ahead in that direction.

[JayaKrishnaNamburu]

We can already achieve this using the project plugins. So, closing the discussion for now.