Closed joepavitt closed 2 months ago
I think the responsiveness of the table gadget has regressed in v 0.10.2?
I now have to stretch my browser over the full width of a 4k + 2k monitor to see the last few columns (in the red square). The lack of a horizontal scroll bar makes it impossible to see the data on anything less than 6k of screen.
I chose to switch to a monospace font (Lucinda Console) with the v1 table to help the readability. I see that the v2 table does not have the option to set the font type at all?
Being able to set the column types is critical, link, html etc (and I see a request in for that), but having only about 5% responsiveness is making it tricky to use. (It does expand and contract around the 5k monitor size, but no less).
Here is the exact same table and data on the v1 dash on the same center monitor and Chrome browser.
New issue opened to track that particular issue, thanks @thebaldgeek
Challenge is is how to detect when to go into responsive mode. It's difficult to judge based on overflow/overlap to then switch, as no JS events are fired in that occasion, and I don't really want to be watching every single cell of a table for overflow manually.
The "easy" here is a screen width option, but similar, if it's just two columns on a mobile, then, in theory, that's fine to render as a table?
I'll move forward with building out the card/mobile view now, but the logic for when to switch to that view needs to be refined/decided - @thebaldgeek thoughts very welcome here.
https://medium.com/appnroll-publication/5-practical-solutions-to-make-responsive-data-tables-ff031c48b122 has a really good summary of the different way to render/handle the responsive layout
The quickest iteration here as it's a single line of missing CSS.
That was a REALLY solid read, thanks for the link @joepavitt I'd like to add a few other options that I think Dash 2.0 (almost) has:
Option to hide columns. I only see this is in the soon coming tabulator node, but is very exiting for my use case. Allowing anyone to tap a column header and chose to hide that column from their view.
This is tricky from a UX perspective, as the default behaviour here is to sort those columns. This would add complexity to that interaction. How do you envision the options appearing?
I found it really easy to do on desktop, tablet or phone.
Click the three dot menu on any column and then select the column you want to hide from there. As soon as you do, the column drops off the table shrinks in width.
Im just unable to get right msg.payload / tablecmd working in Node-RED with the tablulator node at the moment, but will take it up with the dev in a few weeks. Excited to see it in action with real data.
Here it is on the tabluator site: https://tabulator.info/docs/6.2/menu
Going to move this back to the backlog having delivered #829, but won't close as there are iterations we can do here.
This just got a lot easier as Vuetify just released mobile support in their core library:
We just need to pass in the :mobile
property to define when we want the table rendering in mobile/card mode.
That link takes me to a sandbox with a bunch of code. I cant see any hint of mobile support there or how I would add it.
I did find this a little more helpful: https://vuetifyjs.com/en/features/display-and-platform/#usage Seems you can have a few different breakpoints which would be fantastic and very powerful. I'm unsure how to use any of that in Node-RED dash-2 since I recall you mentioning that the template node does not report back to the code running in it the viewport information from the browser. Also their enforced pagination still seems to be strongly in play no matter what you set the breakpoint to be.
That link takes me to a sandbox with a bunch of code. I cant see any hint of mobile support there or how I would add it.
It wasn't in reference to how to use in a Template node, but in reference in our own implementation in core.
The new version of Vuetify (which we haven't pulled into Dash 2 yet) has a new :mobile
property on the data table, when set to true
it will render data cards instead
template node does not report back to the code running in it the viewport information from the browser.
It does have access to the viewport sizing, as that's just a standard JS thing
It can also get the size of itself with this.$el.clientWidth
, which will return the width in pixels
Also their enforced pagination still seems to be strongly in play no matter what you set the breakpoint to be.
As I shared on the forum, there is no enforced pagination. If you're using the Dash 2 table, there is an option in the node's config to turn it off.
If you're writing raw Vuetify in a template, then:
"For those arriving here using Vuetify 3, I've found adding an empty footer slot achieves the same:" https://stackoverflow.com/questions/57371009/vuetify-remove-pagination-on-v-data-table#:~:text=For%20those%20arriving%20here%20using%20Vuetify%203%2C%20I%27ve%20found%20adding%20an%20empty%20footer%20slot%20achieves%20the%20same%3A
Closed by #1206
Description
Proposed here: https://github.com/flowforge/flowforge-nr-dashboard/issues/16#issuecomment-1608288550
Properties
Events
Controls
No response
Existing Examples
Vuetify table: https://vuetifyjs.com/en/components/tables/
This does not include an auto-wrapping to a "card" view as requested though.
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate