…and I extracted the really important(IMO) and historical requests that are needed to take Wappler a bit further. I’m obviously biased towards my own Feature Requests but it’s my post after all and I know how to exit VIM editor.
Apologies if I leave a lot of feature requests out. I’m leaving a lot of mine out also. Don’t take it personally. If it’s out it it’s probably because they can already be implemented via workaround, current extensions or with future extensibility improvements.
So here is the list by number of votes of outstanding FRs that should be implemented 100% no excuses
(This one could be done with a SC extension but requires more hjson options for the UI)
(But change the word Webpack for Vite.)
(…and a graphql server as companion) Could be Apollo.
The next ones are some not-game-changing but really interesting QOL changes that everybody would benefit from:
And these are all related to extensibility of Wappler that is really a MUST because 90% of the outstanding Feature Requests could be built if you guys focus on extensibility during the 5.x life.
I will be updating this list with implemented stuff and new FRs that are interesting. I will also make sure that this is the most bumped topic in the following year.
This is a great list. I agree with the item at the top of the list (Switch Case/Else-If) - I think that’s probably the most important ‘missing’ feature, from my point of view.
The FR with the most votes is probably the one for a Draggable/Sortable component. I expect you might say this wouldn’t be needed if your UI extensibility FR were implemented. However, I don’t think this would be a solution for most Wappler users - and would be quite complex to implement in any case. Also, it would be good to have a new component like this which would be very useful, as well as being more ‘fun’ than most items in the list.
The Custom Blocks FR would certainly be useful, but similar to the snippets request - which has a lot more votes (and would be more useful IMO).
With all or most of the features demonstrated here for example? Creating a table with draggable/sortable rows is quite straightforward, but to create a UI offering the sort of options available in SortableJS for example would be quite a task, I would have thought (not that I have any doubt that you could develop such a feature).
Thanks - I’ll have a look at this. I was thinking of something integrated into Wappler but perhaps it’s not necessary.
Not using that library, but yes. Most of those use cases are covered in mine.
If you guys lobby and manage to make Wappler team add the needed support for AC extensibility(UI, framework tweaks and documentation) within the next 3 months, I will build a sortable.js extension for free and release it Open Source
you made some really good points. Maybe our insistence on these requests will force the wappler team to work a little harder in some respects. but now there is an excellent tool that has been made and I believe it will definitely get better. For this reason, these demands are definitely appropriate and have been determined as a result of the experience of many ambassadors.
I think the first thing to do here is that hjson is more flexible, else if - switch case and then other properties can come. Because these two features are demands that will relieve many users.
Another +1 for extensibility. A lot of the feature requests I have would no longer be a problem if Appconnect hjson and extensibility were implemented/finalized. Described it a bit more here.
But for whatever reason, I have nearly always ended up at Jon’s posts when browsing the forum. So I’m guessing we are often doing similar things. But at the same time, I feel like these things must be done by most Wappler users? For example internationalisation or UI extensions.
