NEW: Workspaces now has a custom shadow-cljs build target. If you use it, it will:

You may still configure it with the old style with the :browser target, but in that case you will always have to add your workspace and test namespaces to your main.cljs file.

Now run with:

For some reason on my tests I couldn’t make Figwheel :on-jsload hook to work with library code, to go around this modify the main to look like this:

So you can call the hook forom there, as:

Now run with:

Usually libraries like Fulcro or Re-frame will manage the state and trigger render in the proper times, but if you wanna do something with raw React, you can provide an atom to be the app state, and the card will watch that atom and triggers a root render everytime it changes.

Important: The react-card is actually a macro, the reason is that we wrap your render call into a function that will only be called when that card is initialized. This prevents the render calls to happen when cards are just loading.

Workspaces is built with Fulcro and has some extra support for it. Using the fulcro-card you can easely mount a Fulcro component with the entire app, here is an example:

By default the Fulcro card will wrap your component will a thin root, by having always having components with idents you can leverage generic mutations, this is recommended over making a special Root. But if you want to send your own root, you can set the ::f.porta/wrap-root? false. Here are more options available:

When you use a Fulcro card you will notice it has an extra toolbar, in this toolbar you have two action buttons:

Fulcro 3 is a rewrite and require new wrappers, for Fulcro 3 we got the portal and the card type in the namespace nubank.workspaces.card-types.fulcro3. The settings are the same as for Fulcro 2, all keywords should be namespaced with the fulcro3 card type namespace.

Workspaces has default integration with cljs.test, but you have to start the tests using ws/deftest instead of cljs.test/deftest. The ws/deftest will also emit a cljs.test/deftest call, so you can use the same for running on CI. Example test card:

When you create test cards using ws/deftest, a card will be automatically created to run on the test on that namespace, just click on the test namespace name on the index to load the card.

When you add any test, you also get a card that will run the whole test suite. You can open this card by clicking at the TESTS in the index, or using spotlight to find the test-all card.

You can define settings for your card, like what initial size it should have, to do that you can add maps to the card definition:

The measuremnt is in grid tiles. A recommended way to define a card size is to add it in default size to workspace, resize it to the appropriated size, then use the Size button accessible from the more icon in the card header, the card current size will be logged to the browser console.

For the built-in cards you can also determine how the element will be positioned in the card. So far we have been using the center card position but depending on the kind of component you are trying that might not be the best option.

The card container is a flex element, so the previous example will put the card on top and make it occupy the full width of the container.

The default ::wsm/align is:

Using the key ::wsm/node-props you can set the style or other properties of the container node.

You will probably find some combinations of card settings you keep repeating, it’s totally ok to put those in variables and re-use. You can also send as many configuration maps as you want, in fact the return of (ct.react/react-card) is also a map, they all just get merged and stored as the card definition.

You can create new workspaces by clicking at the + tab on the interface. The workspaces are created and stored in your browser local storage. You can rename the workspace by clicking on its tab while it’s active.

Your cards are placed in a responsive grid, this means that the number of columns you have available will vary according to your page width size. Right below the workspace tabs you can see how many columns you have available right now (eg: c8 means 8 columns).

Each responsive breakpoint will have stored separated, so you can arange a workspace to fit that available width. The sizes and positions will be recorded separated by each column numbers (they vary from 2 to 20).

Each column size has 120~140px, varies depending on page width.

In the card header you will see the card title (which is the name of the card symbol) on the left, and at the right two icons. The first icon is the ``more'', mouse over it to see some card available actions:

After that you have an X icon to remove the card from current workspace.

Sometimes you want to focus on a single card, like when you want to see just the full test suite or want to have a card that renders your entire app.

In these cases you can open a tab with a card occupying the whole space, you can do that clicking in the Solo button from the card actions, or via spotlight, holding the alt key when clicking or hitting return to select.

When you have an open workspace, there is a toolbar with some action buttons, here is a description of what each does:

A lot of times your workspaces will be disposable, just pull a few components, work and throw away. But other times you like to create more durable ones, like a kitchen sink of all your components buildings blocks, or maybe a setup that works nice for a specific task. You a lot of effort to make it look good on many different responsive breakpoints. So would be a pain if every user of the system had to redo the task to organize those types of workspaces.

To solve that, you can use the Export button on the workspace toolbar. It outputs the workspace layout as a transit data on the console. You can copy that, and use to store that workspace setup on the code, making it available to any other person using this workspace setup.

When you open a shared workspace, you can’t change it, it’s static, but you can duplicate it and change the copy as you please.

The card life cycle happens according the following events:

If we try to use our alignment settings with our new card, you will see it will not work.

This is because the alignment implementation is a wrapper utility, and you have to manually call it to get it’s functionality, let’s see how we can extend our card to support it:

Now we can use the ::wsm/align as usual. I like to point out you can use this strategy yourself to create wrapper functions that can add functionality to a card definition, they are good composition blocks.

Here let’s create a custom implementation for a React card, this implementation will assume the app state is an atom, and will have a timer ticking in a root property on the state atom.

To add a toolbar, you must provide the ::wsm/render-toolbar. This time you must return a React component that will be used as the toolbar. We suggest using components from the namespace nubank.workspaces.ui.core for consistency.

Use this provide extra functionatility for your cards.

You might noticed that the test cards are able to change the card header style to reflect the test status, and you can do this to your cards too.

Let’s add a button on our toolbar to change the header color:

By calling the ::wsm/set-card-header-style you can set any css you want to the header.

That’s all, go make some nice cards!