Module component namespacing causing hell

First of all, I LOVE that Retool finally has modules :heart:
My apps become less bloated as a result. Once JS functions can become first-class citizens instead of transformers, I’ll be a happy puppy.

One problem tho. Module component namespacing is causing a cascading hell. It’s unpredictable, and makes development a headache.

  • Existing custom CSS becomes unusuable, need to use matching selectors, which is not performant
  • triggeredById is namespaced when the module is embedded in a parent (altho, seems like only when a query is triggered by another query)
  • form.data elements are namespaced (e.g. form.data.name becomes form.data[edit_form::name] = value in the parent)

I’m sure there’s more, but I’ve already wasted hours debugging stuff that works perfectly well when I’ve developed a module in isolation, but breaks when I’m actually embedding the module.

The root cause of all issues is that Retool tries to fit all components into a global flat namespace, while components should live in a tree structure. That would solve so many headaches, such as being able to name form elements by the names of the fields without worrying about collision / duplicate IDs, and reduce the amount of boilerplate needed for form data submissions (for example). Traversing the tree will also make it easier to build complex logic in the apps. Google Appmaker did that really well, basically having their own version of a DOM tree of the app.

Hey @lauri, thanks for writing in and checking out modules! I’d love to hop on a Zoom to discuss some of these issues if that’s okay? Will DM you to coordinate

@yogi @lauri did you end up finding any solution to this? we are facing a similar problem!

@lauri @josefran We’ve recently pushed fixes to triggeredById and form data being namespaced when the module is included in a parent app. You should see that in your Retool instance in the next day or two.

As to the CSS issue, I’m taking a look!

1 Like