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.

1 Like

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

@yogi
Another disappointing CSS issue with modules is that if you apply CSS in the App settings (Or even JavaScript)- that does not get applied to the app you put the module in.

For example, say I use the CSS in a module to change the background color for the S3 Upload button. When I add that module to something- the CSS is no longer applied.

I could put it in the root module, but need to make sure the colons are escaped like this: "._retool-jsonPhotoEditor1**::**s3Uploader1 button".
I would really rather keep this in the module's css though.

@Kade333

Hey there :wave: There is an active feature request for this, I just linked it to this thread so that I can update you as progress is made!

1 Like

Seconding (thirding?) for CSS selector inconsistency between module and the module as used in an app:

To get my nav module hamburger menu to right-align (aside: IMO, alignment should be a built-in option on the nav component, that "menu alignment" in the inspector is a cruel tease), I use

._retool-hamburgerNavMenuRight {text-align: right;}

which works great for the module itself, but I've also had to add the awkward

div[data-testid="RetoolGrid:navMenuModule1::hamburgerNavMenuRight"] {text-align: right;}*

globally to effectively style the module across all the apps that use that module – because apparently, the module component's class as described here does not persist through to the actual implementation of the module. It took poring through an app's elements inspector to figure out why the CSS wasn't applying – because the class that you would assume is there, actually isn't!

*@Kade333 after reading your post I now understand why I couldn't get class selectors with :: to work, and why I only had success selecting on the data-testid attribute, where the :: is helpfully enclosed in quotes. The double-asterisk escape in your example wouldn't work for me, but ._retool-navMenuModule1\:\:hamburgerNavMenuRight does work; thank you for tipping me off to the necessity of escaping those colons.

1 Like