What is a panel? This is a fairly simple component, dividing the visible area into 2-3 blocks:

• Cap. The heading and some (usually navigational) board elements are usually displayed in the header.
• Body. Arbitrary content is displayed in the body of the panel. Often this block is made scrolled so that the cap does not go out of sight.
• Basement. Optional unit. This usually displays information and controls common to the contents of the panel.

Despite the apparent simplicity, implementations are usually not so simple. This is due to the fact that there are a lot of options for its use.

The heading may or may not be:

• Headline. Additionally, it may have a subtitle.
• Bread crumbs. They may be part of the heading, or they may be a subheading.
• Navigation links. Such as "back", "next" and so on.
• Buttons. Such as "open filters", "switch flag", "close window" and others.

In short, there can be almost anything in a hat. In the body, it should definitely be possible to display any content. In the basement, the content can also be arbitrary.

It turns out that the panel must have at least 3 parameters that accept "complex content", that is, one that is not flat text, but contains a hierarchy of nested blocks.

Next is an overview of those ready-made solutions that can be found in Google. For each, the implementation size is indicated in lines of code (CLOS). Plus a bonus at the end, for those who get ;-)

Reactjs

wmira / react-panel - 180 CLOS

The header displays:

• Optional icon in front of the heading.
• Actually the title.
• Optional set of clickable icons on the right side of the header.

Body sizes are tuned to content by default. Half-tree is not supported.

Usage example:

return (
    <Panel
        title={Привет, мир!}
        titleIcon="icon-idea"
        toolbox={[
            {
                className : "icon-close" ,
                onclick : this.onClose.bind( this )
            }
        ]}
        >
        <p>Ты прекрасен!</p>
    </Panel>
)

Summary: a solution for a very special case, in the mess code, there is no documentation, only one dubious example of use in the spirit of jQuery.

react-bootstrap - 235 CLOS

The hat and basement are designed to display simple text, but there is the ability to display anything there. The body adjusts to the size of the content and can be collapsed to zero height through the flag.

Usage example:

return (
    <Panelheader={
            <div><spanclass="my-title">Привет, мир!</span><ButtonbsStyle="danger"onclick={this.onClose.bind( this ) }
                    >
                    Закрыть
                </Button></div>
        }
        footer={
            <ButtonbsStyle="success"onclick={this.onSuccess.bind( this ) }
                >
                О, да!
            </Button>
        }
    >
        <p>Ты прекрасен!</p></Panel>
)

Summary: in spite of crutches with wrapping the list of components in a div and stuffing a whole tree into an attribute, you can use for almost everything. Unless “collapse” will often be just an extra burden, and when something special is needed, then this shortcut of implementation is most likely not enough.

pivotal-cf / pivotal-ui - 173 CLOS

The header is divided into two sections: left (header) and optional right (actions), where you can display any content. Basement and body have one section. For the body, you can enable "scrolling" so that the panel does not crawl out of the viewing area.

Usage example:

return (
    <PanelclassName="bg-neutral-10"header={
            <h1>Привет, мир!</h1>
        }
        actions={
            <DangerButtononclick={this.onClose.bind( this ) } >
                Закрыть
            </DangerButton>
        }
        footer={
            <PrimaryButtononclick={this.onSuccess.bind( this ) }>
                О, да!
            </PrimaryButton>
        }
        >
        <p>Ты прекрасен!</p></Panel>
)

Summary: all the same crutches, but the implementation is more compact, contains almost nothing superfluous and a little more convenient to use.

Bike - 44 CLOS

It is somehow not convenient that part of the layout is set in the attributes, and part in the body. Some functions are redundant, while others have to be rewritten to implement others. And since all the same, sooner or later, rewrite, then let's try to rewrite in such a way that it can be flexibly done without crutches.

functionMyPanel({ className , ...props }){
    return (
        <div
            { ...props }
            className={ `my-panel-root ${ className || '' }` }
        />
    )
}
functionMyPanelTitle({ className , ...props }){
    return (
        <h1
            { ...props }
            className={ `my-panel-title ${ className || '' }` }
        />
    )
}
functionMyPanelHead({ className , ...props }){
    return (
        <div
            { ...props }
            className={ `my-panel-head ${ className || '' }` }
        />
    )
}
functionMyPanelBody({ className , ...props }){
    return (
        <div
            { ...props }
            className={ `my-panel-body ${ className || '' }` }
        />
    )
}
functionMyPanelFoot({ className , ...props }){
    return (
        <div
            { ...props }
            className={ `my-panel-foot ${ className || '' }` }
        />
    )
}

The panel consists of 3 optional blocks: cap, basement body. Bonus: you can add several caps / bodies / cellars. For blocks, you can use either standard components from the panel or your own, and place anything inside them.

True, the use is a little more verbose, but there were no tags in the attributes:

return (
    <MyPanelclassName="my-panel-skin-pretty"><MyPanelHead><MyPanelTitle>Привет, мир!</MyPanelTitle><buttononclick={this.onClose.bind( this ) } >Закрыть</button></MyPanelHead><MyPanelBody><p>Ты прекрасен!</p></MyPanelBody><MyPanelFoot><buttononclick={this.onSuccess.bind( this ) }>О, да!</button></MyPanelFoot></MyPanel>
)

Summary: a relatively compact and highly flexible solution, it has a simple, understandable, though somewhat verbose (which is basically XML-specific) interface.

$ mol_pager - 11 CLOS

The header displays the title by default. The contents of any block, like the blocks themselves, can be replaced with anything. The body scrolls, and the scroll position is restored upon reboot.

The implementation is so compact that it’s not scary to bring it right here:

$mol_pager $mol_viewer
    childs /
        < header $mol_viewer
            childs < head /
                < titler $mol_viewer
                    childs /
                        < title
        < bodier $mol_scroller
            childs < body /
        < footer $mol_viewer
            childs < foot /

Usage example:

$my_app $mol_pager
    title \Привет, мир!
    head /
        < titler
        < closer $mol_clicker_danger
            eventClick > eventClose null
            childs / \Закрыть
    body /
        \Ты прекрасен!
    foot /
        < successor $mol_clicker_major
            eventClick > eventSuccess null
            childs / \О, да!

Summary: the implementation is an order of magnitude more compact, which nevertheless provides a high degree of flexibility, use without crutches, but rather unusual syntax is required that requires mastering. And, yes, this is not React, but $ mol , where the interface is also built from components that aggregate other components within themselves, but the components are not recreated during each rendering, but are cached. :-)

findings

In JSX, you can do this and that, but there will still be something wrong. Common problems:

• A hard, non-customizable code that forces you to cycle every time you need to add a pair of mother-of-pearl buttons.
• Extra functions in common components. The consequence of high code rigidity.
• The branchy, inconsistent use interface. Usually the contents of the body are transferred in a way different from the contents of the remaining blocks.
• All react programmers program differently. Who, as I understand it, figsit. And most likely not the way you need it.
• JSX is similar to XML and JavaScript, but it is neither a super- nor a subset of either one. So behind the seeming simplicity lies the need to understand the features of the unique syntax.
• Even a simple component requires quite a bit of code. And the more flexible you want to make it, the more confusing the code will be.
• The structure of the component is smeared evenly according to its logic. Mimicry under XML in this case becomes useless.
• Engaging the coder is only possible after an intensive course in JS ... after which he quits and goes to work as a programmer. :-)

On the other hand, there is a simple and consistent view.tree syntax optimized for creating flexible components with a minimum of source code, and which can be trained by any typesetter in a matter of days, after which its efficiency will significantly increase (it will not have to copy huge pieces of html or manually paste the necessary states to the components) and the programmer’s efficiency (he won’t have to “pull” the layout on the logic every time the layout designer updates the layout).

Even if you handyman full-stack programmer who knows how to use patterns, semantics, and styles - your efficiency will still be improved by reducing the amount of code and the easy and easy creation of components (to create a simple component, just create a file with the contents of one short line )

And how would you implement the Panel component on your favorite framework?

PS. This is not an advertisement for $ mol, it is an advertisement for view.tree. If you are not ready to exchange React for something else, but are interested in the view.tree syntax, you can implement its translation in React. The idea of ​​view.tree is simple: complete component management without leaving an extremely simple language. And scripts with logic on JS / TS are screwed to the side. In the implementation of $ mol, the logic is screwed up by inheriting and redefining the properties specified in view.tree.