"console.log"/preview server connect action

I’m pretty sure I’ve seen this request before but I can’t find it. When I was developing APIs in Wappler it was kind of time consuming checking the right data was being returned in each step.

This is how Console ninja for vscode solves this: It outputs to the VScode editor the result of any console.log output.

For me this is a great time saver.

Sharing it here because I think Wappler could benefit from something like this. I can see this approach working wonders in Wappler.

1 Like

Very interesting, this could speed up development a LOT. Having the ability to run queries now directly in the server action is already a time saver, adding this will really take it to the next level.

2 Likes

This would be awesome.

1 Like

This is kind-of similar to the FR about output-for-debug option (which outputs everything-always), but a step further to show the output in Wappler itself, rather than looking in the browser’s network tab?

1 Like

Yes. Exactly

I’m leaving this here for inspiration as it also has some other cool features that could be useful for Wappler.
https://console-ninja.com/

2 Likes

This would be excellent.

1 Like

This feature request keeps floating around in the back of my mind.
I think this would bring Wappler to another level.

Please consider this @George @patrick :smiley:

3 Likes

I'm in.

Not sure how easy/difficult this would be to implement but from an end users point of view it would save a heap time.

2 Likes

@george and @patrick, is this in your roadmap? this function is mandatory for me to continue using Wappler! I spend many hours finding simple problems, this is fundamental in a lowcode tool that presupposes agility and productivity, as I am currently wasting a lot of time solving simple problems and issues! I hope you understand!

Console.log debugging is only used when building custom modules. In normal server connect usage you can achieve similar results by just adding ‘Set Value’ step and outputting the data.

You can actually do that even for custom modules.

So the output data is just available in the dev tools just as the rest of the data.

So no, this request is not on our roadmap as it is already easily achieved otherwise.

But it is important to understand that just using data evaluation through inspection by the browser or the use of "set values" are insufficient for efficient debugging! This has to be very clear, because even with the use of the "set values" feature, they are only displayed in the last flow and of course there are other ways to get around this, such as using sockets or other ways, but they are resources that we must create, precisely because of the lack of any efficient way to debug what is being written. We need tools that make coding easier and not need to create artificial resources to meet basic needs.

You see this:

1 Like

If the team spent more time developing apps with Wappler they would realize this. Debugging Server Connect APIs was not something pleasant for me.

I remember having to create a custom extension to ease the work a bit.

1 Like

I understand that server side debugging is challenging, but debugging step by step and pausing a server action is technically impossible.

Returning the data is what already happens so having it separately doesn’t strike me as a great addition or maybe I’m missing something?

  1. A user marks a step as logged
  2. SC console.log the data that is output by that step.
  3. Intercept from the dev server the console.log as Console Ninja does.
  4. Present in a panel nicely formatted.
  5. Profit
1 Like

If we can't get the full blown solution, I think this feature request would get us partially there:

We could really use something that differentiates debug output from functionality output.

1 Like

exactly this is a greaty alternative!

Step-by-step debugging and breakpoints are implemented in IDEs such as Visual Studio Code with regular programming languages.

@ everyone The quoted text is not a case of technical impossibility, this is a case of feature request priority ordering, the team finds the engineering effort not worth it, and I understand because I agree it takes a lot of time to do it right

Well we will see what we can do, it will be a technical challenge, but there might be more possibilities in NodeJS for visual debugging of the data and direct execution in Wappler. Might be a good feature for Wappler 7 :slight_smile:

2 Likes

Happy to see it's being considered :slight_smile:

1 Like