# Increase canvas size? (supersize flows!)

**URL:** <https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855>\
**Category:** General\
**Created:** [28 August 2019 15:17 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855 "2019-08-28T15:17:25Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![swiftnesses](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@swiftnesses](https://discourse.nodered.org/u/swiftnesses)\
**Post date:** [28 August 2019 15:17 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/1 "2019-08-28T15:17:25Z")

</div>

Good day,

I've become fairly involved with Node Red and have a few flows that exceed the width of the canvas, can this be increased via a setting? (fingers crossed it can!).

Many thanks for this amazing tool.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [28 August 2019 15:20 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/2 "2019-08-28T15:20:00Z")

</div>

Hi @swiftnesses

no, the workspace is hardcoded to 5000 pixels wide and high.

---

<div class="post-metadata">

**Author:** ![swiftnesses](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@swiftnesses](https://discourse.nodered.org/u/swiftnesses)\
**Post date:** [28 August 2019 15:20 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/3 "2019-08-28T15:20:41Z")

</div>

Ouch, time to rethink my deployment...

---

<div class="post-metadata">

**Author:** ![JayDickson](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jaydickson/32/90592_2.png) [@JayDickson](https://discourse.nodered.org/u/JayDickson)\
**Post date:** [28 August 2019 15:34 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/4 "2019-08-28T15:34:19Z")

</div>

If you're running a fairly recent version you should be able to hide your labels on nodes to shrink them down real nice. You may also have some success with subflows, especially if you have recurring functional structures.

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [28 August 2019 18:31 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/5 "2019-08-28T18:31:14Z")

</div>

Also using links to transfer/access data onto different tabs.

---

<div class="post-metadata">

**Author:** ![tilleul](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tilleul/32/78_2.png) [@tilleul](https://discourse.nodered.org/u/tilleul)\
**Post date:** [2 September 2019 15:56 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/6 "2019-09-02T15:56:14Z")

</div>

Any chance this might be customisable in the future ?  
Also, I noticed that you can't move nodes outside those limits using the mouse but you can using the keyboard !

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [2 September 2019 16:13 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/7 "2019-09-02T16:13:52Z")

</div>

> [@tilleul](#):
>
> Any chance this might be customisable in the future ?

I don't know. Depends if someone wants to take it on. Otherwise it'll sit in the backlog with everything else.

---

<div class="post-metadata">

**Author:** ![swiftnesses](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@swiftnesses](https://discourse.nodered.org/u/swiftnesses)\
**Post date:** [4 September 2019 21:06 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/8 "2019-09-04T21:06:59Z")

</div>

Wish I had the skills, I'd love to implement this feature. Out of curiosity, where is this hardcoded?

BTW, I really appreciate this awesome tool, it's literally redesigned how I interact with technology!

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [4 September 2019 21:15 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/9 "2019-09-04T21:15:41Z")

</div>

[https://github.com/node-red/node-red/blob/master/packages/node\_modules/%40node-red/editor-client/src/js/ui/view.js#L19](https://github.com/node-red/node-red/blob/master/packages/node_modules/%40node-red/editor-client/src/js/ui/view.js#L19) and 20  
then you have to rebuild the project.

---

<div class="post-metadata">

**Author:** ![bakman2](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bakman2/32/6207_2.png) [@bakman2](https://discourse.nodered.org/u/bakman2)\
**Post date:** [4 September 2019 21:26 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/10 "2019-09-04T21:26:23Z")

</div>

> I really appreciate this awesome tool, it's literally redesigned how I interact with technology

Well it was designed with tabs 😉

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [4 September 2019 21:37 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/11 "2019-09-04T21:37:06Z")

</div>

and links to connect them...  
and subflows to encapsulate functionality into a single node...

---

<div class="post-metadata">

**Author:** ![swiftnesses](https://avatars.discourse-cdn.com/v4/letter/s/f17d59/32.png) [@swiftnesses](https://discourse.nodered.org/u/swiftnesses)\
**Post date:** [4 September 2019 21:58 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/12 "2019-09-04T21:58:10Z")

</div>

It was meant as a compliment 😊

---

<div class="post-metadata">

**Author:** ![guysqr](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/guysqr/32/11551_2.png) [@guysqr](https://discourse.nodered.org/u/guysqr)\
**Post date:** [4 September 2019 22:11 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/13 "2019-09-04T22:11:08Z")

</div>

I would just echo what others here have said about subflows and links - you're almost certainly better off breaking down your flow into smaller logical chunks. Sounds like you have built yourself a monolith!

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [6 September 2019 06:03 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/14 "2019-09-06T06:03:52Z")

</div>

That really depends on your use case. I am all in for creating and reusing components with subflows, but in some projects, it is really _that_ much. We had to split one logical topic into multiple tabs, because there wasn't enough canvas space (at least vertically).

And that leads to the next issue, when you get too many tabs... 🙈

> [@Editor Feature Request - Flow List Quick Navigation](https://discourse.nodered.org/t/editor-feature-request-flow-list-quick-navigation/3634/14):
>
> I think that would be just a short-term solution to the real issue: a better overview and navigation of your tabs in larger-sized projects. We have projects at work with +30 tabs. Hiding any of them would not make sense, as you often need to jump between them. That is really painful at the moment, even with the new search box. (I can give a more detailed description of our use case, if anyone is interested) A tab list that uses the vertical space, that is always visible and scrollable by mouse…

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [6 September 2019 08:02 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/15 "2019-09-06T08:02:15Z")

</div>

> [@kuema](#):
>
> And that leads to the next issue, when you get too many tabs

When you are getting to this point, I would have to be questioning whether you are using the right tool for the job?

I would certainly be looking closely at resource utilisation and I would also be looking for areas of my flow that could be simplified, refactored or rewritten in code as a single function or even a custom node. Are there parts of the flows that could be more effectively written as a separate service or module?

I would also be asking devs some very careful questions about maintainability and documentation. How easy is it to understand those flows? What happens if your main devs leave? How long would it take for someone new to come in and understand such a large set of flows?

Node-RED is a fantastic tool but it isn't the tool for every job.

Just a few thoughts with my IT manager hat on.

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [6 September 2019 11:28 UTC](https://discourse.nodered.org/t/increase-canvas-size-supersize-flows/14855/16 "2019-09-06T11:28:22Z")

</div>

Okay, let me explain our use case a little deeper.

**Background:**

We are a manufacturer of _custom_ engineering lines, so each project has different requirements. These can be a quite large lines of connected physical processes.  
In our terminology, a line consists of different **modules** , each module has one or more **stations**. At each station there can be one or more physical **processes**. Each part (the product) is handled through the line and is usually identified by a unique ID.

Physical processes can be screwing, joining, pressing, measuring, welding, laser processes, ...  
you name it.

**Use case for Node-RED:**

We are using Node-RED as a data processor between the field (Siemens PLC, low level) and higher level systems (databases, the customer's MES, etc...).  
It is achieved by some custom nodes for the PLC communication and decoding/encoding of raw data structures.

We already try to keep the flows as simple as possible, so complex functions are put into stand-alone services that are just invoked by Node-RED.  
Node-RED is merely the "man" in the middle. 🙂

Per station we have to handle different kinds of requests from the PLCs, like the following:  
part check-in

- can the part be processed in this station?
- retrieve production parameters (limits for measurements, program parameters  
for external devices, ...)

part check-out

- process part-related data (hand over to customer systems, internal  
databases, ...)

A common flow looks like this, simplified.

`plc in` -\> `decode struct (raw bytes)` -\> `process` -\> `call a service api` -\> `generate response` -\> `encode` -\> `plc out`

This is usually a one- or two-"liner" including a `catch` node for error handling in each flow.

Each flow involves more or less unique data structures, depending on the physical process. These are decoded into an object using a structure definition (Siemens SCL).  
Generic stuff is put into subflows and now that these are customizable with parameters (v0.20), they have become really useful!

**Regarding the canvas space limitation and tab navigation:**

For now the common practice is to put these flows for checkin and checkout requests for each module into a tab. So you would get "M1 - checkin", "M1 - checkout", ... for module 1. Now imagine a production line with 10-15 modules and at least 10-20 different requests per module that need to be handled.

So the number of flows required scales with the complexity of the line (number of modules/stations/processes).

**To address your concerns:**

The runtime can handle this amount of processing perfectly. 🚀 That is exactly  
what NodeJS (and Node-RED) was made for. It is merely a matter of the  
presentation in the flow editor and how you can navigate your flows.

From the perspective of software development in the context of _custom_ mechanical engineering, doing all this with Node-RED gives us exactly the flexibility we need. There is often a requirement for "special" handling due to customer wishes. Furthermore, each customer has different backend systems.

Compared to our previous solution, we can apply changes _a lot_ more quickly, now even at runtime. The initial setup of new projects is easier.  
And you can actually **see** what is happening with your data and why, making it easier for colleagues to become acquainted with the project's specifics.

From that experience the last 1-2 years, I believe moving to Node-RED for that  
kind of stuff was a perfect choice. 👍

Quite a lot of text.... I hope I wrote it in an understandable manner. 🕶