Your Best "Commenting" Methodology?

Hey Wapplers, what’s your best method of commenting your pseudocode logic into your apps? We know SC-side supports commenting your thinking just fine, but what’s your trick to gracefully commenting your logic on the appconnect side, without having it render-out to the page source?

Not everyone wants a self-note of: “Hey moron, don’t touch or edit this logic in the future without first checking x y z” actually rendered in the page source ha.

I’m personally a heavy-documenter as I have the memory of a canary, so looking for any tricks for putting as much notes in the code as possible without spilling anything to the users.

1 Like

Meh, well of course all it took for me to figure it out was to post the question.

Use a conditional region always set to false.

image

Any other tricks like this still welcome.

You can keep all the (goofy) comments you need in html, css, and js files as part of the source files. This will help you and anyone that works with the code understand better what’s happening and the mood you were in when working :joy:

It’s not uncommon to leave those kind of funny comments.

Then as part of your CI/CD pipeline you can remove all comments when deploying to production. Normally through minifiers.

I know that CI/CD might sound daunting at the beginning but it’s something your can start small(like minifiers) and once you feel more confident you can keep adding things.

I would suggest against using conditional regions for two reasons:

  • They are visible if you know how to look for them. Like adding a breakpoint before App Connect is loaded and runs the dmx-if render/update methods.
  • They have to be evaluated by App Connect so depending on the number they might have a performance hit.

Not that the conditional region is a no-go for hiding comments, but minifying and striping out comments before deploying is a best/accepted practice.

3 Likes

A gold reply, thank you @JonL!

1 Like

If you don’t want comments to render on clients you could add some PHP or EJS around them:

PHP (for you @jonl :stuck_out_tongue_winking_eye:):

<?php if(false){ ?>
	<!-- Some comment I want to hide -->
<?php } ?>

NodeJS:

<% if(false) { %>
    <!-- Some comment I want to hide -->
<% } %>
2 Likes

Or, with PHP, just have regular PHP comments:

<?php
// Any comment you like here
?>
3 Likes

Totally more efficient :+1: - I thought the condition could surround existing HTML comments without having to adjust them

1 Like

That’s probably the first time ever I’ve been referred to as ‘more efficient’!!! :rofl:

3 Likes

Fascinating discussion!

Some of you may have found that there is an issue with comments on the client side… when you move things around in the App Structure panel, normal comments don’t move with the thing they are commenting!

So I’m wondering whether you could put these funky PHP comments inside an innocuous html element that you can see there and move around too… :thinking:

Maybe an aside?

I don’t know why in the world I didn’t consider just manual in-line EJS comments. (Node) Thanks so much for the duh-level slap upside the head.

Thanks for dropping that thread @Antony, interesting read on the history. All of the proposed methodologies would be fine, EXCEPT for that they all expose the comments in page render.
My .02 for a built in Wappler functionality would be implementing something like an external config, a lot like what is done for query defs and other things that are hidden for security. So every element could have an optional config entry to store the internal Wappler-level comments. This way it doesn’t matter where on the page elements get dragged around to, and exposing the comments can be a simple as clicking on the element and reading it in the Wappler properties panel.