Wappler Version : 6.7.1
Operating System : Windows 11
Server Model: Node.js
Database Type: SQL Server
Hosting Type: AWS
Expected behavior
listen to message calls from sockets
Actual behavior
I don't hear calls from sockets messages
How to reproduce
just create a socket with some UpperCase letter that when defined in dynamic events/type the event is not fired, when using lowercase it works correctly.
When I used lowercase it worked perfectly, but I spent several (many!) hours to reach this conclusion, due to the difficulty in debugging with the platform. I suggest investing in the resource to improve debugging, because although there are some resources inspecting the browser, many server-side executions, we do not have access to execution phases. And many cases are simply ignored without any response to a simple error such as this in naming.
In the browser, got to dev tools. Usually by right-click and inspect, or press F12.
Go to Network tab.
In network tab, find the filter WS (WebSocket), and select that.
Here you will see the current active socket connection as "pending".
Click on it to view details on the right.
In details section, click on Messages tab.
This is where you will see all the messages being exchanged between client and server. Here' you could have seen the difference in case.
Its sort of a policy/guideline in our company to always use kebab-case for API, schedulers, socket messages etc entries. So did not even know that this restriction exists. Good to know.
ok @sid , as I said, there are some resources to debug, using F12 as you show, I already used it, but it's so bad we found problems in the backend process, we need to put variables and create gimmicks to see the bugs! The Wappler team needs to know about this weakness to make Wappler better! Efficient debugging makes understanding easier for new users, as well as saving hundreds of hours spent locating simple errors.If kebab-case is the default choice, why let the user create a free sockets name, but when calling, it doesn't work? Do you agree that it is necessary to create a policy that regulates the creation of names? Avoiding future call errors, like what happened to me?
That definitely has been a pain point since the beginning. But its never been a deal-breaker for me at least. There are some feature requests around making SAs easier to debug, but don't think any of them have been implemented yet.
Its our default choice - our coding practice, not something that is required.
A similar issue exists with dynamic classes - you cannot have camelCase classes as dynamic.
This is not something that can be done. Coding in general is a very personalized thing. There are numerous guidelines out there on best practices - but none of them are forced.
The improvement needed here is clear documentation - which again has been a problem from the beginning - given the very dynamic nature of Wappler with weekly updates.
@sid, I used some uppercase letters to define the name of a socket, but to use it, it must necessarily be with lowercase letters, that is, yes, there is a restriction that is not required when creating the socket, but in use it does not work if it does not follow the defined standard, that is, this "freedom" does not exist, or else, the use that the developer uses must be respected, be it uppercase or lowercase, but the biggest problem would not even be this issue of nomenclature but rather the difficulty in debugging , where the sockets responses even appear using the browser debug, but the dynamic event was simply not being triggered, which makes it difficult to identify the source of the problem, as well as other occasions, where the error is simply ignored by the engine, which makes it difficult and We end up wasting a lot of time on simple problems and the use of nocode platforms should focus on saving time for their developers, in other words, I think I'm providing valuable feedback, naturally the value is only perceived if well understood. Anyway, thank you for your messages.
I believe that the Wappler tool is good, but it requires investment in documentation, training and especially a better way of debugging and criticizing and controlling the code generator. The vision of creators using the tool with a mind clear of concepts they already know is important, that is, as we use the platform and suffer a lot, a lot and we learn, but spend a lot of time. Naturally, most people don't have this patience and end up switching tools. Anyway... I believe that investments in this area will keep customers and not expand them! Gaining customers is not an easy task, and they can easily be lost.
And that is a Wappler problem. Which needs to be addressed in the tool and their docs.
Its not necessarily a limitation of socket.io which is the underlying library. And if it is indeed a limitation from socket.io, its again on Wappler to convey that - hence the bug report is valid.
Definitely. The feedback is helpful.
There have been numerous discussions in the past about the huge learning-curve of Wappler, difficult onboarding and stickiness etc. Things have slightly improved over the years, and it seems the numbers are working out for the team (even) in the current state - else they would have shut it down.
