App states

Apps in the drop-in UI can be open or closed. It is mainly just a visual state, but also affects performance and some functionality. By default apps are open when loaded, but if you want an app to start in the closed state you can specify open: false when initializing the app.

Open and close

Opening and closing an app can be done with the .open() and .close() methods. When any app opens or closes there is also corresponding event fired which makes it possible for your application to react when this happens.

Weavy also has built in support for toggling an app, which switches the UI state without having to keep track of whether the app is open or closed. This makes it easy to set up a sliding drawer or an expanding area for the app.

To toggle an app, you simply call the .toggle() method of the app. This will open or close the app depending on the state, then trigger a toggle event followed by an open event or a close event.

Using the open/close functionality and events is benefical if you have apps in panels, tabs or other containers that has changing visual states. Placing your UI state modifiers in the open or close event will make it possible for weavy to open the correct visual state for a specific app when needed. For instance if you in click a link to a document in the files app, Weavy will be able to trigger the correct visual state to show the app.

Even more benefit is added if you configure navigation handling, since Weavy will be able to trigger correct visual states without additional complex logic added when navigation is performed.

Grouped apps

Weavy may also handle switching between apps. This is can be done by placing the apps in the same container and setting a group name option for the apps to switch between. When one of the apps is opened, the other apps in the group are closed. When using groups, none of the apps in the group are opened automatically by default, unless you set open: true on the app you want to be opened at start.

Grouped apps may be handled in two ways:

  • If you use .open() each app will be switched to when called, the same way as normal tabs.
  • If you instead use .toggle() the app will be switched to or closed if already open, which is great if you want to combine a sliding drawer with tab functionality.
let app1 ={ group: "my-drawer", type: "notifications", id: "my-notifications" });
let app2 ={ group: "my-drawer", type: "messenger", id: "my-messenger" });


Each app has the following methods for handling the visual state.

Method Description[url]) Opens the app. May also load an optional url.
app.close() Closes the app
app.toggle([url]) Opens/closes the app depending on state. Closes related apps configured in a group. May also load an optional url on open.


Putting your UI state modifications in an event handler to show a sliding side panel for instance is mostly less work than you think. It's more about the flow order when opening that panel. Let's say you're adding a class ".open" to change the visual state of the container when you click a button. To involve weavy in handling the visual states would simply be to put the adding of the ".open" class within the open event and instead let the button trigger the .open() method of the app.

Event Data
"open" { app, destination }
"toggle" { app, closed }
var app ={ id: "myapp", type: "messenger" });
// Listen to an event in a specific app
app.on("open", function(e, open) {
   // Do something

The app events propagates from the app to the weavy instance. This means you can set up a handler for the event on both the app and on the weavy instance. Events from all the apps will fire on the weavy instance, so you need to check which app that has fired the event.

var weavy = new Weavy();
var app ={ id: "myapp", type: "messenger" });
// Listen to an event in a specific app
app.on("open", function(e, open) {
   // Do something
// Listen to an event from any app
weavy.on("open", function(e, open) {
   // filter out a specific app
   if ( === "myapp") {
       // Do something
Weavy Docs