You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the time this issue is being filed, Zui is at commit 28aede8.
In the first version of Preview & Load, the user is presented with an empty editor in which to draft their shaper. We're aware that this will not always be ideal, and indeed one of our own community members that tried out the feature in Zui Insiders gave this feedback in a Slack thread. In their own words:
A button to save/ load shaper scripts would be nice 😬
Indeed, when @jameskerr and I exchanged thoughts as the feature was being built/tested, here's a few ideas we came up with.
For the case when a user is dragging more data to add to an existing pool, it might be handy if the editor could be pre-populated in this case with a cached copy of the last shaper used for load to that pool. At one point during development the editor contents always held the shaper contents from the last load even if it was for a different pool, and I recommended taking that out because different pools are likely to hold different data/types and hence are likely to need different shapers most of the time. But by comparison, I expect existing pools are often going to see loads of additional data of the same type, so caching the last-used shaper for that pool seems like it would be a handy convenience.
In @jameskerr's own words from the task list in Preview & Load Feature #2834, it might be handy to have a dropdown near the editor that offers shapers to choose from. When one is selected, its code would then appear in the editor for possible further editing, in which case being able to Save/Save As might also be justified. Since Saved Queries are already a concept in the app and any Zed program could potentially act as a shaper, I feel like it would be reasonable for the selection mechanism to just be a way to select from all Saved Queries. If a user has a workflow where they have specific, purpose-built shapers, they'd be free to organize them into specific/named folders to suit their needs (i.e., I'd not advocate having some kind of special, pre-allocated Saved Queries area just for "shapers").
As another way to invoke previously-used shapers, at one time I think @jameskerr imagined using some of the empty white space on the Pool Summary page to have "hot areas" that mention recently-used shapers, such that if a user drags data into the app and over the hot area for a particular shaper, it would start the Preview & Load workflow with that particular shaper already loaded into the editor. Perhaps the recently-used shapers for that particular pool could be shown first in the order, but other frequently-used shapers used regardless of pool could come after, filling in however much of that blank space we feel is appropriate. Another nice convenience would be if those same "hot areas" could serve as a way to quickly peek at a shaper's code, i.e., pop up their code when the user hovers over them with the mouse when not dragging data, or when clicking on them.
The text was updated successfully, but these errors were encountered:
At the time this issue is being filed, Zui is at commit 28aede8.
In the first version of Preview & Load, the user is presented with an empty editor in which to draft their shaper. We're aware that this will not always be ideal, and indeed one of our own community members that tried out the feature in Zui Insiders gave this feedback in a Slack thread. In their own words:
Indeed, when @jameskerr and I exchanged thoughts as the feature was being built/tested, here's a few ideas we came up with.
For the case when a user is dragging more data to add to an existing pool, it might be handy if the editor could be pre-populated in this case with a cached copy of the last shaper used for load to that pool. At one point during development the editor contents always held the shaper contents from the last load even if it was for a different pool, and I recommended taking that out because different pools are likely to hold different data/types and hence are likely to need different shapers most of the time. But by comparison, I expect existing pools are often going to see loads of additional data of the same type, so caching the last-used shaper for that pool seems like it would be a handy convenience.
In @jameskerr's own words from the task list in Preview & Load Feature #2834, it might be handy to have a dropdown near the editor that offers shapers to choose from. When one is selected, its code would then appear in the editor for possible further editing, in which case being able to Save/Save As might also be justified. Since Saved Queries are already a concept in the app and any Zed program could potentially act as a shaper, I feel like it would be reasonable for the selection mechanism to just be a way to select from all Saved Queries. If a user has a workflow where they have specific, purpose-built shapers, they'd be free to organize them into specific/named folders to suit their needs (i.e., I'd not advocate having some kind of special, pre-allocated Saved Queries area just for "shapers").
As another way to invoke previously-used shapers, at one time I think @jameskerr imagined using some of the empty white space on the Pool Summary page to have "hot areas" that mention recently-used shapers, such that if a user drags data into the app and over the hot area for a particular shaper, it would start the Preview & Load workflow with that particular shaper already loaded into the editor. Perhaps the recently-used shapers for that particular pool could be shown first in the order, but other frequently-used shapers used regardless of pool could come after, filling in however much of that blank space we feel is appropriate. Another nice convenience would be if those same "hot areas" could serve as a way to quickly peek at a shaper's code, i.e., pop up their code when the user hovers over them with the mouse when not dragging data, or when clicking on them.
The text was updated successfully, but these errors were encountered: