Hi All, I'm very pleased to announce that we've just hit a big milestone with the development effort on Node-RED Dashboard 2.0 - we've just released our first major version - v1.0.0:
You can read more about it here: Node-RED Dashboard 2.0 is Generally Available! • FlowFuse
I have only followed this peripherally till now, will my old dashboard import or am I looking at a total do-over?
Do-over unfortunately. Completely new architecture under the covers.
I do have a plan for a migration script to automate some of it but it's not going to be a 100% automatic process.
I do have a very detailed migration guide too which covers the (currently) covered features: Dashboard 1.0 Migration Guide | Node-RED Dashboard 2.0
Total do better. Cos it is possible and you can!
Luckily you can run both at the same time - albeit separate endpoints/pages - so you can keep some old pages while you migrate over.
This is awesome!
I really appreciate your effort and your responsiveness in getting issues and new features turned around. Thanks!
Took my spare pi loaded up bookworm and node red and node20, copied over one existing flow and ta da!!! nothing, sigh, read the docs and I'm committed to migrating but this looks like a huge hill.
No. And that's the sad case of course. I'm kind of feel a little pressure to migrate some of my more popular widgets to DB2 but yeah, it takes quite of resources to invest.
Morning @hotNipi,
Yes indeed same feeling here...
The only positive thing is that the new ui nodes will be better, because @joepavitt has worked tremendously hard to provide us a better framework. But of course that means you have to rethink your entire design: no last msg replay, server side state, ...
During the christmas holidays I started (with some help from Joe) migrating my node-red-contrib-ui-heatmap node. And yes it needs to be developed completely from scratch. I think it is about 80% finished, but I had to put it temporarily aside due to less of free time unfortunately. I have even no idea when to start with my other ui nodes.
And for those who will be wondering - whenever I find time to migrate my ui nodes (svg, babylonjs, multistate switch, ...) if they can simply replace their old ui nodes by the new ones in their flows. The answer will be: no. Even if I would have plenty of free time, there is lots of functionality that sneaked in based on feature requests from users, but which turned to be a bad idea afterwards. So I would never add those features again in their current state. Moreover by reading tons of feedback about problems that users e.g. had in the past with the lack of a server side state, I would surely do things differently this time based on the ideas that they shared...
As I offered to @BartButenaers, I will also offer the same to @hotNipi - I'll happily help pair program on calls, make improvments to contribution guides, even get started on the dev effort myself to get initial framework/structure setup for you all.
Appreciate its a big, intimidating hill, and want to do all I can to help.
If your flows included original Node-RED Dashboard nodes, you will still need the original Dashboard installed.
Node-RED Dashboard 2.0 is an entirely new package.
I tried a bit. Kind of something can be done. It takes time to try it out for all possible widgets but I tried with some.
For group add the class
and that bit of CSS override for page:
.condenced-layout{
--layout-gap:0px;
--widget-row-height:24px;
}
.condenced-layout .v-card-text .nrdb-ui-widget{
padding-inline:.5em;
align-items: center;
}
.condenced-layout .v-btn.v-btn--density-default{
height: fit-content;
}
.condenced-layout .v-input--density-default {
--v-input-control-height: 26px;
--v-input-padding-top: 8px;
}
Maybe consider migrating to HTML standard web components that could be used in DB1, DB2, UIBUILDER, http-in/-out, ....... ?
Absolutely. It maybe should be explained a bit in detail what it does so the one can improve it more easily if needed.
That was my wish for the db2 solution but there's no Santa.
But true. If it will be one for all, the Earth will be happy. Think about the energy savings....
Indeed. But the use of VueJS does not preclude writing components in standard HTML that can be consumed in multiple places.
Great work, thanks @joepavitt
I think the only things now stopping me moving over to using D2 in 'production' are the missing feature that allows Switches to show the state of the Input (#210) and the fact that when a dropdown is clicked on Android that it pops up the keyboard on top of the dropdown list (#331) and finally, again on Android, the fact that pages left in the background do not update to current values when the page is accessed again (#444), which is a serious issue. I wonder whether the same issue is seen on PC browsers if the tab (or PC) is suspended, I will test that.
[Edit] Having tested, if the PC is suspended and changes are made to, for example, Switch positions, then when the PC is resumed the dashboard does not show those changes, I suspect the same will happen if the browser suspends a tab. I think this is a pretty serious issue.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy