Reimagined data picker

Wappler General
1

I would love to see a reimagined data picker at some point, or at least a serious overhaul. Perhaps a 4.0 feature.

Some specifics:

Needs to properly handle complex objects.

Today we have support in data stores for complex structures like this:

Screen Shot 2021-04-15 at 3.25.44 PM
Screen Shot 2021-04-15 at 3.25.44 PM570×754 29.6 KB

But then in the picker we have this:

Screen Shot 2021-04-15 at 3.26.26 PM
Screen Shot 2021-04-15 at 3.26.26 PM1294×1352 83.4 KB

Yes, I can manually enter those complex structures or use other data stores as sub-parts, but it’s a pain.

And then of course there is the constant battle with the actual selections. It feels like the team is playing whac-a-mole trying to support the various possibilities of nested data, array indexes, etc. Fix one bug, another one pops up. The picker is a fundamental driver in Wappler, yet it always has issues or limitations.

Too often I now just manually type things in, which produces errors. I can fix those, but it really slows things down.

Formatters
The data formats far too often gives the wrong set of options for the data type. It also has trouble with nested arrays with indexes, etc. Problems similar to the data binding picker.

Multiple levels: I can’t find a specific right now, but I know I run into situations where I can’t select another data binding.

Expanded code view:

Because of the current limitations, this is way too small:

Screen Shot 2021-04-15 at 3.28.32 PM
Screen Shot 2021-04-15 at 3.28.32 PM940×368 14.3 KB

This is obviously a very off-the-cuff post…not an in-depth analysis of the picker…but my gut tells me that a reimagined picker would be a real time-saver.

I’m wondering…Are others spending as much time in code view as I am!

5 Likes
2

We basically develop the complete application in code view.
I personally use the picker a bit more since it has improved in terms of listing of elements and searching, but for formatter part or even the design view, I almost never use the UI.

All the points you have shared are exactly how our experience has been too with the pickers.
The very small design & code window is another UI pain I would like to add to the list of issues - along with the recent formatting issues with custom HTML & complex structures.

As much as I like the idea of a better dynamic action picker & a dynamic binding picker - I have absolutely nothing to compare it to for reference design.
It would be great if you could share some ideas which might get the ball rolling for inputs from other members & overall a good starting point for the team.

4 Likes
3

Hi Ken,

I initially thought because of the subject that you are talking about the Data Pickers dialog. We have quite a lot of those. Special App Connect Data Pickers, depending on the user components on the page, Server Connect Data Pickers depending on the data of the server connect action steps.

But then you show your App Connect Actions dialog and I saw that you actually mean that you need a richer input for the nested objects in Data Store. Managing a whole nested data structure, with just a single insert record - is a difficult topic because you have to specify all the nested data. Some might be missing or optional other. Same also for the update record. What exactly do you want to update from the nested data?

So exactly on which direction do you request an improvement for? Maybe try to clarify more in detail, give some examples and ideas of improvements.

In the App Connect Data pickers all formatting and data types are picked up automatically from the schema, if the schema is unavailable than it is indeed more difficult as Wappler can not know how your object looks like.

Maybe some examples so we can anticipate on those.

So try to split the request in more specific requests as "Data Pickers" is just a way too broad aspect in Wappler. So are you talking about picking data, making expressions, or data manipulation in data store? Or data Formatting with the formatter. Also is it for App Connect or Server Connect?

4

Same here. I use complex nested layouts so 80% of the time the object/element I need doesn’t appear in the data picker.

5

This to me, is the real opportunity for Wappler. Shouldn't code view be the safety net, not the primary?

Generally I want nested data supported, everywhere in the editor. But a couple examples.. I want to be able to update an array that is within a data store, or a single record of that array. Or, I want to be able to update a variable that sits underneath an object in a data store.

It often fails to do this, and with everything coming from server connect actions or app connect sources, it should have the schema, right?

This actually supports my request as-is. I'm thinking big here, not patching something. I'm thinking how wonderful it would be if there was actually one picker to support everything. I thinking about a picker that is considered from the ground up, since Wappler has evolved in so many ways since the picker was created. I'm saying that the picker in many ways IS Wappler and that it needs a refresh.

For example, perhaps clicking and picking is just not the right way to do this? Maybe it should be a mini-code view (like the small window provided today) that auto-completes as the user types?

Now of course, perhaps I'm alone in that. :slight_smile: Or perhaps it is not a high enough priority. I would absolutely understand that. I just think it is an opportunity to upgrade something at the core of Wappler.

I would love to provide a solution here, however product design is not to be done from the outside. There is too much I don't know about the inner challenges of this complicated task. I can't spare the days is takes to properly consider this, only to find there is no appetite to update, or that I missed a key requirement. As George notes, it is a difficult topic.

I will end with this, understand that there are users out there that would like to use the pickers, but cannot because they have limitations. Assuming there is no big refresh, I'll put in specific requests as George is requesting.

6

Well you are missing 80% of Wappler functionality and productivity. If you miss some structure that should be available. Please report it in a separate topic.

7

But the data store is already an array that you just add and update records to. That is its purpose. And you can easily insert or update single records of it.

Do you want to nested arrays in the data store? Like arrays in arrays? I wonder what the use case is for that?

8

Unfortunately until you guys support nested layouts there is nothing much you can do I am afraid.

I am deviating from Wappler standard.

Data picker only checks head page, but not grandparent head and children :slight_smile:

9

Still having difficulties to grasp if you mean the data picker or data manipulation or just expressions building?

We already have one picker for picking data. Not sure what is wrong with it yet... if you are just missing some data to pick from, you should just report that.

But at the end of the day it is about data binding picking so you just open and pick it visually by exploring the data structure. Having a code view with autocomplete will fully undo all the visual advantage in exploring and picking data.

10

Okay, no big change desired. Got it. I'll report the smaller pieces and hope they are worked.

11

Its a hit on productivity for sure, but Wappler design view is not built for the complex apps our team has built on it.
And its unfair to ask for it too since there are many use cases which are one-off and very specific. There is no way Wappler can handle everything.

Its very difficult to report every single thing. Also very time consuming, and extremely difficult to track since posts here often get lost with sometimes 0 replies from the team or other members. @mebeingken is great at reporting bugs I think, but even his posts sometimes go unattended.
I have tried to improve and report more, but a dedicated support would be a different story.

In my opinion code view gives Wappler the power to be an all purpose web development tool. I agree that the design view should be smart enough to handle complex structures, but there is no limit to that complexity hence impractical to expect UI to do everything. Wappler is NOT a no-code tool.

12

The biggest challenge with the data picker is that you can pick from so many different sources.

For example you have dynamic attributes in app connect and pick expressions for those and those come from the various data sources on your page. But if it is a content page then it depends on where the page is included in.

Maybe we should just box the scope to the current page and that’s it. If you need data from outside you should pass it as parameters. That is what other frameworks like react do with their components.

And that is just client side data. Now in node you can have also server side data and binding and you can mix all that with your client side data and also with your node templates. And that makes it very complex.

To address that we think to make all NodeJS templates data also available in app connect so you can just pick it as predefined client side data as well.

13

Thanks for noticing @sid! And it IS frustrating to see them unattended. I'm by no means insisting my bugs be fixed, but I do insist they go through triage and have some communication as to what will/will not be done. I've asked for a proper bug reporting system, but the team is not interested. So at this point, I report only a fraction of the bugs I see.

1 Like
14

I hope you understand George, I know what a big complex issue this is. I know it is hard, and I know you guys are working on it, as I see it improving. And because it is such a complex issue, this is why it is such an opportunity for Wappler. As I said, in many was it is the core of the editor.

If that simplifies the issue, I'm all for it. It could be much like the output option in server connect actions. Just tick a box when it is needed downstream.

15

George, correct me if I am wrong. The AC data picker checks the head page and matches it with meta data from the config file right?
Could it be possible for us to decide what meta to bring to the data picker for each page?

As a default yes the head page, but it would be great to be able to let the data picker know we want it to show data also from other pages.

16

Well I’m all in for new features and redesign but I just fail to see where are you exactly pointing at… the data picker, the data view component, NoSQL document database support, formatters or expression builder…?

17

Yes that is exactly what it does - if there is a head page appointed it includes the current content page there and presents the whole full data structure for picking.

You can already choose the head page on the app root properties so you can change it as you wish.

18

With nested layouts I need to include from two or three pages. Depends on the level of nesting.

19

But why? You really should avoid including from global parents and make the content pages more stand alone instead of adding dependencies.

You can pass global data as page parameters and use that one.

This makes your app much more manageable and the content pages/partials more reusable as parametrized objects.

20

That sounds like a really interesting suggestion.
Although, as @George points out, there are too many different sources for data picker, and all work in a different context too. Also, talking about this in action picker context is another complexity.
So not sure if this is feasible as it will be an additional step for the developer to mark components to be available in the pickers. But if there is some way to make it work, it would be really great as it will also speed up the loading of list of items in the picker.