Examples for more complex applications needed. about brick HOT 6 CLOSED

This is a great question and one that gets at the heart of how you can get the most out of the library.

The short answer is that what you draw depends on one and only one thing: the application state. So if you need to make decisions about what to draw, the information that informs those decisions always goes in the state.

Let's say we have an app that has two "screens" - a main list an an editing interface for elements in the main list. Here's a way to program it. I've omitted some details just to provide the structure so you can see how you'd transition between interfaces and draw them. I'm assuming for the sake of illustration that the Enter key is used to switch between interfaces. The key is to use events to set a flag in the state that tells the drawing function which interface should be drawn.

data Screen = MainList | EditForm

data MyState = MyState { screen :: Screen, ... }

draw :: MyState -> [Widget]
draw st@(MyState MainList ...) = [drawMainList st]
draw st@(MyState EditForm ...) = [drawEditForm st]

myEvent :: MyState -> Event -> EventM (Next MyState)
myEvent st e =
  case screen st of
    MainList -> handleMainListEvent st e
    EditForm -> handleEditFormEvent st e

handleMainListEvent :: MyState -> Event -> EventM (Next MyState)
handleMainListEvent st e =
   case e of
    EvKey KEnter [] -> continue $ st { screen = EditForm }
    ..

handleEditFormEvent :: MyState -> Event -> EventM (Next MyState)
handleEditFormEvent st e =
   case e of
    EvKey KEnter [] -> continue $ st { screen = MainList }
    ..

-- Then create an App with the above event-handling and drawing functions and state type.

from brick.

To see this pattern in action you can take a look at this application:

https://github.com/jtdaugherty/dbmigrations-client/tree/master/src

See Types.hs for the application state type, UI.hs for the drawing function, and Events.hs for the event-handling function.

from brick.

If that application I mentioned helped, then please feel free to close this issue. I don't plan on adding more sophisticated examples to the library at this point because my goal is different, which is to keep the example programs as simple as possible while only showing how to use one feature or set of related features at a time. If the documentation doesn't tackle the design questions, I can address those there.

from brick.

You can get some more ideas from this prototype, though it is in flux and may not at all represent best practices.

from brick.

Oh, yes. The application helped very much, and after lots of refactoring, I actually managed to make the code a lot nicer.

from brick.

Great!

from brick.