decorator for Component

[tchaikov]

hello, i am wondering if following helper would be useful?

template <typename Func, typename Decorated>
concept IsDecoratorOf = requires(Func func, Decorated decorated)
{
  requires std::same_as<decltype(func(decorated)), Decorated>;
};

template <typename Func>
requires IsDecoratorOf<Func, Component>
Component operator|(Component component, Func&& func)
{
  return func(std::move(component));
}

template <typename Func>
concept HandlesEvent = requires(Func func)
{
  { func(ftxui::Event()) } -> std::same_as<bool>;
};

template <typename Func>
requires HandlesEvent<Func>
auto handle_input(Func&& func)
{
  return [func = std::move(func)](Component component) {
    return ftxui::CatchEvent(component, [func = std::move(func)](Event event) {
      return func(event);
    });
  };
}

auto quit_on_char(ftxui::ScreenInteractive& screen, char ch)
{
  return [&screen, ch](Component component) {
    return ftxui::CatchEvent(component, [&screen, ch](Event event) {
      if (event == Event::Character(ch)) {
        screen.ExitLoopClosure()();
        return true;
      } else {
        return false;
      }
    });
  };
}

this would allow us to put something like

screen.Loop(document | quit_on_char(screen, 'q'));

i found it's quite handy when adding event handler for a component when developing a complicated interactive application.

if we want to be compatible with older C++ standards, where the concepts are not available, like C++17, we could just drop the constraints, or guard the requires ... block using

#if defined(__cpp_concepts)
  #define CONCEPTS(x...) x
#else 
  #define CONCEPTS(x...)
#endif

[ArthurSonzogni]

I believe a "component" decorator, similar to the "element" decorator is worth doing. That's a good idea!

We can also make the "CatchEvent" and "Renderer'" decorator:

auto component = component
 | CatchEvent('q', screen.QuitClosure())
 | CatchEvent('+', [] { count++; }
 | CatchEvent('-', [] { count--; }
 | CatchEvent(Event::Return, [] { count = 0; }
 | Renderer([] (Element e) { return vbox({e, text(count};});
 | Renderer(border)
 ;

Do you have other ideas, on top of CatchEvent and Renderer ?

[tchaikov]

yes, indeed. but i am not sure if the needs only apply to me, or i am no alone. let me elaborate a little bit on my tiny application first.

i am working an application with couple views:

1. a list / table based view. please think about the github web interface for viewing pull requests. and user is able to create new entries by, for instance, pushing "a", and delete the selected entry, by pushing "d", or manipulate the selected entry by pushing "enter".
2. and user should input more details in the pop-up dialog window. or confirm or cancel the operation by pushing "OK" or "Cancel" button.
3. the operation might fail, or the input parameters are not supported. so yet another pop-up window should show up.

all the windows are stacked. i think the way to stack them is to use dbox(). but to ensure that the event is routed to the right child component, we need to use a container. since Container::Tab() is used by examples/component/modal_dialog.cpp, so i think that's the way to go. but it'd be a pain to manage them manually. so i came up with a helper like

auto WithOverlays(const ftxui::Components& overlays) {
  return [& overlays](ftxui::Component component) {
    return ftxui::Renderer(component, [&overlays] {
       ftxui::Elements children;
       for (auto overlay : overlays) {
         children.emplace_back(overlay->Render());
       }
       return ftxui::dbox(children);
     });
   };
}

ftxui::Components overlays =  {list_view};
auto container = 
  Container::Tab({list_view, add_view, delete_view, warning_messagebox}, &active) | 
  CatchEvent('a', [] { overlays.push_back(add_view); active = 1; }) |
  CatchEvent('d', [] { overlays.push_back(delete_view); active = 2; }) |
  WithOverlays(overlays);

probably without introducing yet another Container which exposes pop() and push() support hiding the combination of Tab and dbox, it'd be difficult to generalize this functionality with an elegant API..

[tchaikov]

oh, another thing came into my mind!

probably a show_if() decorator, but this one is for Element.

template <typename Func>
requires std::predicate<Func>
auto show_if(Func&& func)
{
  return [func = std::move(func)](ftxui::Element element) {
    if (func()) {
      return element;
    } else {
      return ftxui::emptyElement();
    }
  };
}

i will create a PR for this change if it is worthy. this helper is supposed to work along with Maybe(). where Maybe() decorates a Component, but some times, we want to also accompany the rendered component in Render() with a label or a separator, in that case, without the knowledge of the connection between the label/separator and the component, Maybe() is not able to hide them, so we have to add an empty Node in place of the "cake" and the icing on it.

[ArthurSonzogni]

show_if() sounds similar to the Maybe Component, except that the later handle declaring whether it is "Focusable()" or not.

I think I am fine with introducing:

• The operator|(Component, Decorator) -> Component.
• Override for existing components, so that they can be used as Decorators:
  • CatchEvent
  • Maybe
  • Renderer

Happy to do it myself, or let you do it. It's up to you.

[tchaikov]

show_if() sounds similar to the Maybe Component, except that the later handle declaring whether it is "Focusable()" or not.

unless we have a way to hide/show a bunch of connected rendered elements in a functional style, they are not quite the same.

I think I am fine with introducing:

• The operator|(Component, Decorator) -> Component.

• Override for existing components, so that they can be used as Decorators:

  • CatchEvent
  • Maybe
  • Renderer

Happy to do it myself, or let you do it. It's up to you.

#354

only one thing -- can we make Decorator a template? and add ElementDecorator for the decorator for elements?

[tchaikov]

and, we could have a decorator version of Maybe() as well, and to make it accept a templated predicate functor parameter! if it sounds like a good idea as well, i will submit a PR as well !

yeah, this should fall into the category of Renderer() decorators. IMHO, to pipe the decorators with | would be more readable.

[ArthurSonzogni]

ACK, this sounds like a good idea (I replied on the previous thread)