🎇 FlexDash alpha release - round 2

Yes! Your suspicion is correct and I didn't realize the change in behavior when I released or I would have done something different. My apologies for messing up.

What's happening is that widget output messages has a msg._fd_socket field and widget inputs act on the same field. So if you connect an output message to an input you will only affect the specific browser tab that produced the output. To affect all browsers (and future ones) you need to delete the _fd_socket field.

As a twist, if you use the internal loopback (checkbox on the general tab) then that always affects all browsers (i.e. ignores the internal _fd_socket).

I know I have work to do to make all this more obvious/usable. I didn't realize that what I pushed was going to mess something up.

1 Like

It's in alpha, I expect things to get broken :laughing:
Now it's broken, it's an opportunity for me to look at things again, and make my flows better.

1 Like

Oh, just to be clear, what you need to do is:

For input widgets whose state reflects global state, i.e., they should have the same state in all open browsers, you should either use the built-in loopback option or you should delete the _fd_socket field from messages fed into the widget.

What is new is that you can have per-browser tab UI. For example, say you have a toggle to show active vs. inactive gizmos in a table. You want each viewer to choose which to show. Then you use the output of the toggle to put the data for the table together and you inject that into the table with the same _fd_scoket. To see the toggle state you need to use an external loopback keeping the _fd_socket.

Update:
My plan to make this a little mistake-proof is to add a setting to grids with the following options:

  • disallow _fd_socket: drop messages with _fd_socket in all widgets of this grid and produce an error message, this is the default setting
  • allow _fd_socket: allow messages with and without _fd_socket in all widgets of this grid
  • require _fd_socket: drop messages without _fd_socket in all widgets of this grid and produce an error message

This means that by default all state is global. The "require _fd_scoket" setting is useful if you have a grid with stuff you always only want to show per-browser and you want to ensure no global changes sneak in by mistake. I'm not sure it's practical, may need some tweaking, e.g. to allow an initial global message.

1 Like

Already fixed thanks.

Sounds good :+1:
Keeping 'all state as global' as a default will create a good starting point for users.

1 Like

Edit panel of grid config nodes now has:

And error messages like:
image

(My test grids are called "unicast" and "broadcast" which makes the error message ending sound a bit strange.)

:rocket:

I'm also making progress on the FlexDash ctrl node to receive browsing updates and control some internal state:

Node to observe and control some internal FlexDash state, such as currently shown tab as well as features of tabs, grids, and panels.

Output messages are generated for a number of events with the following payload:

  • type: the type of event.
  • cause: user/message for events that can be caused by user action vs. a message.
  • name: the name of the node representing the FlexDash element associated with the event.
  • node_id: the ID of the node representing the FlexDash element associated with the event.
  • title: the title of the FlexDash element associated with the event.
  • icon: the icon name of the FlexDash element associated with the event (for tabs only).

Also, msg._fd_socket identifies the browser tab.

The events types are:

  • new client: a new browser tab has connected, msg.browser is an ID assigned to the the browser using a cookie, it is the same for all tabs of the browser.
  • idle client: a browser tab has disconnected and not reconnected in a few seconds
    (it may reconnect an unbounded time later).
  • change tab: the tab shown to the user has changed. msg.cause is user, message, hide, or expose. The last two refer to the browser window becoming invisible and visible again due to the user changing browser tab, minimizing the window, etc.

In the case of cause==hide the fields identifying the tab will be null/missing.

  • close grid: the pop-up grid has been closed or the regular grid has been rolled-up.
  • open grid: the regular grid has been rolled-down.

Input messages must have a msg.action field and they must target a component by setting either msg.name, msg.node_id, msg.title, or msg.icon (see output messages for details).

The set of actions is:

  • change tab: change the tab to the one targeted.
  • edit: edit the targeted component, setting one or multiple properties to the corresponding values in msg. Supports tabs, grids, and panels. Grids support an additional show property which rolls up/down standard grids and pops up or hides pop-up grids.

Note that the msg._fd_socket is supported and can be used to target individual browser tabs.

3 Likes

I'm probably getting over-excited and am as usual over-optimistic, but are we approaching beta yet? To me beta means that the functionality has stabilized, i.e., big breaking changes are not expected. There is still a list of open issues but they're narrow is scope and have work-arounds.

To start, I updated the list of issues posted oct 9th:

  • Toggle and other input feedback/loopback has to go through server
  • Sending one value to plots or sparkline doesn't work when browser is refreshed, need to fix implementation :stop_sign:
  • Log line "Sending config to ... from store undefined" is confusing
  • Panel shows a ripple on click, it shouldn't.
  • TimePlot is blank if both axes are used and the data for one of the axes is all null (prob. uPlot bug)
  • TimePlot should support SI prefixes
  • When there are many time plots on a page the tooltip can appear in the wrong plot (needs clean repro)
  • TimePlot: remove circles for data points when there are few points
  • TimelinePlot needs to be clickable
  • TimelinePlot: look into supporting multi-line labels
  • TextView: provide option to wrap text, also to scroll to bottom
  • Button: look into 100% width option as well as FAB support
  • Figure out support for per-connection data (not released yet)
  • Support simple login
  • Option to hide edit mode
  • Maximized plots that have no title end up w/out close button (needs repro)
  • Allow tables to be magnified full-page
  • Implement a search in SimpleTable
  • Fix initial "expose" tab-change event on intial page load
  • Look into socket.io inactivity timeout on server end
  • Think about arrays and per-socket data 'cause array topics are global, e.g. delete-array-element is global
  • Document the fact that internal loopback is broadcast, or rethink the functionality
  • Use material design color palette for graphs to unify color names
  • Roll NumberField functionality into Stat widget and perhaps TextField into Label. :stop_sign:
  • Edits in the live dashboard get lost if a related edit panel is open in the flow editor and is subsequently saved
  • Implement UI to reorder grids on a page :stop_sign:
  • Rethink editing in live dashboard: could reordering/resizing be done nicely without? :stop_sign:
  • Triple-check implementation of "node is truly deleted" in node-red-flexdash and actually delete references :stop_sign:

Keen observers will notice that the list has gotten longer :roll_eyes: but I think the impact of the items has narrowed. Most fall into the category of bug fixes or enhancements to one or two components, which is something compatible with being in beta. I marked the items I think need to be addressed before declaring beta with a stop sign. Thoughts?

The one big item that is not on the list is a big refactoring to support arbitrary nesting of container components in the dashboard. I need to think about it some more, but I have the feeling it would be a big stability set-back at this point and better reserved for FlexDash V2. I believe it can be done without big impact on users.

1 Like

Imho if you are happy with the global design, and your design is capable to implement most of the (currently known) required features, and you don't expect breaking changes anymore soon. Then indeed I would go to beta phase.

A big applause and thank-you-for-all-the-hard-work-for-this-community :partying_face: :champagne: :clinking_glasses:

But unfortunately I think you forgot a very difficult item on your TODO list: convince the developers of the old UI nodes, that they should really start find some free time to start migrating their stuff to Flexdash :wink:

3 Likes

Heh, the old timers are welcome to stick to the ui nodes :joy:
Maybe in a bit some of us can get together and do a "node of the week" thing: have users propose "if FlexDash had node X I would migrate", then pick one a week, and implement it. :boom:

NB: I have lots of stuff in FD I'd like to redo & refactor, but if I start it's never gonna get to release state...

1 Like

Trust me - I don't need convincing... just time... someone still has to keep an eye on the old code... hopefully I may get some time over the holidays to dip my toes in.

6 Likes

Hmmm, you're likely to spot stuff that needs fixing, I look forward to hearing about it!

Do you think it is useful to create a separate thread about ui node migration, from old dashboard to flexdash? We had some discussions about that some time ago. But perhaps you have gained new insights, during your journey...

Where the data is stored, how updates of that data need to be done, how to reload that state after a restart, and so on...

1 Like

I think it's premature to talk a lot about migrating nodes, or at least, I don't have the bandwidth to do so. If anyone has a node they'd like to migrate I'm more than happy to help if they start a thread and flag me.


Following my post How to track dependencies between nodes I now have one more item for my to-do list :

  • remove all editing from FlexDash and implement live reordering/resizing in the flow-editor...
1 Like

Thanks for your work on FlexDash, I will try and keep my questions here short and to the point as I value your time to give some input.

My Node-RED dashboard has around 1000 users a day.
It uploads around 1Tb of data since any one page loads the whole site.
(Painful thread here: How to make Dashboard webserver more robust?)

FlexDash quesitons:

  1. Does loading one FlexDash page load the whole site?
  2. Does FlexDash use ExpressJS / Socket.io? (From the above link, I'm led to believe this is a bad thing for me if it does).
  3. Is FlexDash multi-user aware? ie If one person does a search does everyone get those results showing up everywhere like the current dashboard?
  4. I think I can run FlexDash and the stock dash together? ie, I cant take my current site down while I migrate to the new dash. I need the same URL path but different tabs for example.

Thanks for your help.

Ben

[quote="thebaldgeek, post:140, topic:67783"]

  • Does loading one FlexDash page load the whole site?

Yes & no. All the widget config is loaded but if you have pages (tabs) that have particularly heavy data (e,g, graphs with lots of data) then with the next release you could send that on-demand when the user navigates to that tab.

  • Does FlexDash use ExpressJS / Socket.io? (From the above link, I'm led to believe this is a bad thing for me if it does).

Yes it does. Could you elaborate on what the problem is? (I'll check the link)

  • Is FlexDash multi-user aware? ie If one person does a search does everyone get those results showing up everywhere like the current dashboard?

With the last release it is multi-user aware and with the next release that will be fully usable. I need this for exactly the reason you allude to.

  • I think I can run FlexDash and the stock dash together? ie, I cant take my current site down while I migrate to the new dash. I need the same URL path but different tabs for example.

FlexDash can run on the NodeRED server mounted at an arbitrary URL or on a separate port at the root. So yes, you should be able to run the two side-by-side (and you can iframe std dashboard tabs into FlexDash tabs pretty seamlessly).

I'm happy to answer more questions here, but if you'd like to dive in deeper just open a separate thread and @tve.

Thanks for replying....
One main question I had and somehow forgot to ask...
I read your GitHub page and saw no mention of a table gadget.
My site makes VERY heavy use of data dense tables, are tables something on your roadmap to add?

FlexDash has a PropsTable and a SimpleTable. Here's a small example:
image

The columns are sortable and you can get an event when a row is clicked. I use this on a DHCP table to pop-up more info about the device clicked. The pop-up is a grid with arbitrary widgets, so you can do some amount of drill-down like that.

The main limitation of the SimpleTable is that the cells have plain text. I want to add a table widget that lets you put arbitrary components into the cell so you can display whatever you want, but until the CustomWidget landed I didn't have the infrastructure for it. I also need to think a little about exactly how to do it...

Im wondering... in regard to the 'per user' access you are looking to add....
Will that add a user/pass for each user, or retain the current global (one for dash and one for the editor) one that Node-RED already has?

It's gonna come in stages...

What I have ready for release is session management, specifically, having a persistent session for a browser tab across websocket reconnects. This allows sending data to just one browser tab so pop-ups, search and stuff like that can be made to function the way most users expect.

I also now assign a cookie to a browser for "persistent" identification. This is what is needed to do auth in the end, but I haven't implemented full auth. I only have pieces of it so far. I will need something a bit unusual for my own needs so I don't know about a general solution, not that there usually is anything like that in either the authentication nor the authorization domain...

WRT the one that NR already has... unfortunately the auth in NR was designed so it cannot be reused and I don't know whether any of it can be made to gate access to FlexDash due to the way socket.io works with Express...

Dunno whether that answers your question...

1 Like

145 messages... time to move to the next thread...
Please continue in ✨ FlexDash alpha release - round 3
Can a moderator kindly lock this thread?