Signed-off-by: stroblme <stroblme@posteo.de>
This commit is contained in:
2026-08-19 13:08:31 +02:00
parent ce6701f74c
commit 5d1d8ab3c3
+6 -3
View File
@@ -15,7 +15,6 @@ should reopen it.
- BUG/UI when enlarging the code editor of a node, the code editor should enlarge to the left (node settings remain on the right) so that the code editor fills the center of the screen with the node properties available next to it - BUG/UI when enlarging the code editor of a node, the code editor should enlarge to the left (node settings remain on the right) so that the code editor fills the center of the screen with the node properties available next to it
- BUG/UX the console/log panel does not show print output of nodes - BUG/UX the console/log panel does not show print output of nodes
- BUG/UI find a good way to represent the dictionary style of messages (truncated test, click to enlarge.. ). Show dtype instead of actual values -> actual values when clicking expand
- BUG/UI loop-lag in home view can't have a value when there are no flows (push back if I'm wrong here) - BUG/UI loop-lag in home view can't have a value when there are no flows (push back if I'm wrong here)
- BUG/UI brain view in the home view should be hidden when there are no flows/nodes - BUG/UI brain view in the home view should be hidden when there are no flows/nodes
- FEAT/UI in addition to the two issues above we should introduce a default flow and dashboard for every new user. These should be very minimal to quickly understand what's happening but still show off most of the features of the application. We could make this optional by offering a "Create Demo" button showing at the location of the brain view if there are no existing flows. This demo could then also serve as a demo.fluksio.com site later to play around without signup - FEAT/UI in addition to the two issues above we should introduce a default flow and dashboard for every new user. These should be very minimal to quickly understand what's happening but still show off most of the features of the application. We could make this optional by offering a "Create Demo" button showing at the location of the brain view if there are no existing flows. This demo could then also serve as a demo.fluksio.com site later to play around without signup
@@ -37,6 +36,9 @@ should reopen it.
- FEAT/UI/MOBILE: a rank of many nodes — a connector feeding eight dashboard tiles — is thousands of pixels wide however the graph is turned, so on a phone the fit shrinks it past reading. The layout is right and the flow is simply too big for the screen; a "one rank at a time" reading mode, or wrapping a wide rank, is what would make it legible. - FEAT/UI/MOBILE: a rank of many nodes — a connector feeding eight dashboard tiles — is thousands of pixels wide however the graph is turned, so on a phone the fit shrinks it past reading. The layout is right and the flow is simply too big for the screen; a "one rank at a time" reading mode, or wrapping a wide rank, is what would make it legible.
- CHORE/UI: an edge's value chip sits at the bezier midpoint while the layout reserves its room at dagre's label rank. The two agree closely enough today; if chips ever pile up, take the position from the layout instead. - CHORE/UI: an edge's value chip sits at the bezier midpoint while the layout reserves its room at dagre's label rank. The two agree closely enough today; if chips ever pile up, take the position from the layout instead.
- FEAT/UI (deferred until MCP lands): add a "bot" icon button to the home view (graph panel) which opens a chat window (reuse general concept of a side panel like in flows/nodes to make it a chat panel which can open on any screen (stacks below any other existing panel -> introduce stacking) to give support on errors/write code, generate dashboards etc) to explain the error(s) - FEAT/UI (deferred until MCP lands): add a "bot" icon button to the home view (graph panel) which opens a chat window (reuse general concept of a side panel like in flows/nodes to make it a chat panel which can open on any screen (stacks below any other existing panel -> introduce stacking) to give support on errors/write code, generate dashboards etc) to explain the error(s)
- FEAT/UI make the header (Fluksio - YEAR) and the logo in the sidebar link to the main page (fluksio.com)
- FEAT/UI consider adding a diagram to the Home view which shows a histogram of the different classes of nodes and which time it takes to execute (logarithmic scale); this should give a hint on the load and help to detect bottle necks/hotspots
- FEAT/UI streaming edges should get animated (moving dashs) to indicate this type of output visually
### Persistence and databases ### Persistence and databases
@@ -105,6 +107,7 @@ Decisions taken up front, because most items below depend on them:
- Structured data reaches a widget as a *declared shape*, not as opaque JSON with - Structured data reaches a widget as a *declared shape*, not as opaque JSON with
a path per binding. A path would leave the picker with nothing to offer and a path per binding. A path would leave the picker with nothing to offer and
`widgetIssue` unable to judge a tile from the document alone. `widgetIssue` unable to judge a tile from the document alone.
- BUG/UI double check that this aligns with the new data-science pipeline feature
- A chart asks a flow for its series the way every other input widget speaks: - A chart asks a flow for its series the way every other input widget speaks:
it publishes a request message and reads the answer. No query API, no it publishes a request message and reads the answer. No query API, no
database knowledge in the widget. database knowledge in the widget.
@@ -152,7 +155,7 @@ Decisions taken up front, because most items below depend on them:
chart publishes its request, so the token needs that one write scope. chart publishes its request, so the token needs that one write scope.
- FEAT/UI: per-dashboard theme — forced light, forced dark, or switched on a - FEAT/UI: per-dashboard theme — forced light, forced dark, or switched on a
schedule. View mode inherits localStorage and the OS preference today, which schedule. View mode inherits localStorage and the OS preference today, which
a panel in a room has no way to set. a panel in a room has no way to set. NOTE: to solve this, we could introduce a general message sending to the overall dashboard (so far we only treat widgets in a dashboard as a receiver). We could e.g. have a toggle in the dashboard settings which says "propagate theme" which enables a field for defining a consume input (identical to a standard node input) and then a node can connect to this property by producing a corresponding message. This would nicely generalize to other dashboard settings later. This could later also serve as a security mechanism, i.e. the possibility to lock down dashboards remotely
- FEAT/UI: page navigation in view mode. `/view/{name}` renders the first page - FEAT/UI: page navigation in view mode. `/view/{name}` renders the first page
and offers no way to reach the others; the editor side of this is the and offers no way to reach the others; the editor side of this is the
multi-page item under *Dashboard follow-ups*. multi-page item under *Dashboard follow-ups*.
@@ -212,7 +215,7 @@ as an em dash.
Open on purpose. Each names what should bring it back. Open on purpose. Each names what should bring it back.
- PERF/UI: the app's entry chunk exceeds the warning threshold. React Flow and Monaco are already lazy; a manualChunks split measured no better, so this needs route-level work on the shell rather than chunking config. - PERF/UI: the app's entry chunk exceeds the warning threshold. React Flow and Monaco are already lazy; a manualChunks split measured no better, so this needs route-level work on the shell rather than chunking config.
- PERF/UI: the Monaco chunk is 2.6 MB. It only loads when a node panel opens, but the editor could be trimmed further or swapped for CodeMirror if that becomes a problem. - PERF/UI: the Monaco chunk is 2.6 MB. It only loads when a node panel opens, but the editor could be trimmed further or swapped for CodeMirror if that becomes a problem. NOTE: switch to codemirror; loading speed is definitely an issue.
- CHORE/API: node source saves carry no version precondition, so two clients editing the same node's code are last-writer-wins. The flow document is what the optimistic lock protects; code files would need their own, and an exact-match one produces false conflicts against a single client's own interleaved flow and source saves. Revisit with the M5 multi-user work. - CHORE/API: node source saves carry no version precondition, so two clients editing the same node's code are last-writer-wins. The flow document is what the optimistic lock protects; code files would need their own, and an exact-match one produces false conflicts against a single client's own interleaved flow and source saves. Revisit with the M5 multi-user work.
- CHORE/FLOW: shared node sources bypass the draft/publish split. Editing one writes the library copy and reloads immediately, since the code is not any single flow's to hold back. Deliberate, but it means a shared node is the one thing publish does not gate. - CHORE/FLOW: shared node sources bypass the draft/publish split. Editing one writes the library copy and reloads immediately, since the code is not any single flow's to hold back. Deliberate, but it means a shared node is the one thing publish does not gate.
- CHORE/INFRA: `requires-python` is capped below 3.14 because the MCP SDK wants a newer starlette there than the pinned `sentry-sdk<2` allows. Lift the cap when sentry-sdk moves to 2.x. - CHORE/INFRA: `requires-python` is capped below 3.14 because the MCP SDK wants a newer starlette there than the pinned `sentry-sdk<2` allows. Lift the cap when sentry-sdk moves to 2.x.