Is there any way to work in the design view with test data so that text widths can be previewed more accurately? It’s a big frustrating to see “Parent group’s event’s date:formatted as …” It’d be a lot better to see the actual date formatted for a preselected data value.
I could submit a feature request, but I can’t be the first person needing something like this.
Any suggestions to improve the design view?
Hi there, @PBFC… I’m sure what you are suggesting has been brought up before, but it doesn’t stick out to me as something about which folks have regularly expressed frustration over the years. I’m guessing the reason for the lack of frustration is that what you want in the editor is exactly what the preview mode is for, and even if you had it in the editor, it wouldn’t be “accurate” because you are still viewing it within the context of the editor rather than seeing it the way your users will see it on their screens.
You can submit the idea to the ideaboard if you’d like, but I honestly wouldn’t expect the editor to change in the way you are suggesting any time soon, if ever.
Best…
Mike
Fair answer. Thank you.
it takes some getting used to but you learn to ignore it because once you start to know what kind of data is going to be populating those cells you dont really care what the contents of those cells look like in the editor.
its all about getting those expression correct.
This issue feels more important than the thread is suggesting.
This is a small change that would make the design process significantly faster.
The whole point of using no code is so you can code visually rather than imagining the page, then refreshing, then imagining it again, etc.
Having a live preview of the page would save 3 seconds of refreshing the /version-test page in a separate window. Seems like a small 3 seconds but it would be a game changer.
Caveat - you could let users toggle between live data view and variable name view.
But what data would it use?
Just display the data that is being called. For example instead of showing Parent group’s Plan’s product name:lowercase, just display premium
In the case of a repeating group, you could show the first row’s data only (rather than showing infinite rows).
In the case of a repeating group, you could show the first row’s data only (rather than showing infinite rows).
The first row of what data?.. from who’s or what data would you be showing the first row from?
What if the data source was dynamic based on conditionals, custom state values, or User data?.. What data would it show then?
And how would that help with design if you’re only seeing a single database entry (would that be from your dev or live database) when different data could be 3 words or 250 words?
What if the data source was not coming from the database, but some other source, such as an API call, custom state (that doesn’t exist in the editor), or an on-page input? (or URL parameters)…? how would any of that work in the editor? How would you account for privacy rules or User roles?
What data would you expect to see in the editor then?
And how would any of that help you with design (given the dynamic nature of the data… if anything it would make it harder?)
I’m not really seeing how this could possibly work… nor what advantage this would have over just understanding that the Editor is for developing, and Preview is for previewing the page with live data)…
A Page will look different at run time depending on where the data is coming from, who is trying to access that data, and what permissions they have to view that data
It seems to me is would make things more complicated, not less…
The key thing is - these variable names refer to actual data.
There is always real example data you can use. But which data to choose in the case where there’s multiple options? Just pick a reasonable default.
Really hope someone at Bubble thinks this through because it would make a big impact on the design speed imo.
Reasonable by what measure? (I literally can’t think of workable example here)
In any case, I can’t see how this would help with design at all if you’re working with dynamic data (there are too many variables to make it useful), and it would almost certainly slow down (or complicate) development (even if it somehow speeds up design).
It’s. Never. Gonna. Happen. Anyway. 
I actually understand why you would want this feature since sometimes the current placeholder text does get very long.
There is a method in which i use, but very rarely and hence why I don’t see any justification to make it default.
All i do is go to conditions, set the action of the conditional to a sample text (or whatever works) and just turn on the condition. It’ll produce an error since there is no condition so I’ll just go back to fix it before deploy.
If you click the “preview” button, what data appears? Use that data.
It feels like a no-brainer to me. The below UI isn’t helpful.
I think if you need to preview the text in the editor, @ihsanzainal84 's comment above really would be a great way to go for alot of text fields.
In your screenshot, it looks to me that the text fields are stretching outside of their element. Are you using the columns layout, or align to parent? (i’m assuming you’re in the new responsive engine)
What i usually do is have the maximum width field set, and then check the box for “fit to content” so that the text field can shrink if needed, but also can grow to it’s maximum size in the editor.
This gives you a visual preview of what it loads like, but just not the data that’ll be there.
