feat: add a ‘lib/demo/ui’ package

[moul]

The goals are to provide a way to:

• build UIs with more go and less markdown,
• make realms’ code more readable thanks to widgets (breadcrumb,
• have consistent interfaces from a realm to another,
• later, to support extended markdown options (Proposal: extend markdown rendering #439),
• encourage people building/extending UI frameworks with a first one (of a long series?).

PS: I don’t like the current API, but I wanted to crash test something, then iterate.
I will probably switch to a single generic type Element structOrInterface{Prepend, Set, Append}.
Opinions are appreciated.

Demo:

import "gno.land/p/demo/ui"

func Render(path string) string {
	var dom ui.DOM
	dom.Title = "UI Demo"
	dom.Header.Append(ui.Breadcrumb(
		ui.Link{Text: "foo", Path: "foo"},
		ui.Link{Text: "bar", Path: "foo/bar"},
	))

	dom.Body.Append(
		ui.Paragraph("Simple UI demonstration."),
		ui.BulletList(
			ui.Text("a text"),
			ui.Link{Text: "a relative link", Path: "foobar"},
			ui.Text("another text"),
			ui.Bold("a bold text"),
			ui.Italic("italic text"),
			ui.Text("raw markdown with **bold** text in the middle."),
			ui.Code("some inline code"),
			ui.Link{Text: "a remote link", URL: "https://gno.land"},
		),
	)

	dom.Footer.Append(ui.Text("I'm the footer."))
	dom.Body.Append(ui.Text("another string."))
	dom.Body.Append(ui.Paragraph("a paragraph."), ui.HR())

	return dom.String()
}

Addresses #903

[tbruyelle]

I like the simplicity of the API thanks to the stringer interface, I think it's good enough but probably I lack experience in writing complex Render methods to have a worthwhile opinion.

Can you elaborate a little bit more why would you prefer something like type Element structOrInterface{Prepend, Set, Append} ?

[moul]

Thanks @tbruyelle 🙏

I may have gone overboard with defining too many structs/interfaces. Consolidating them into a single ui.Element struct could improve readability and reusability. Although I typically prefer breaking down larger structs, in this instance, combining them might be more advantageous.

As for the API, we can merge it now and create a competing alternative ui2 at a later time. What are your thoughts on this?

[tbruyelle]

Yes I'm for merging it now, so we can easily complement @alexiscolin's work like for ui.Jumbotron().

Currently I had to rebase your branch and push it to my fork with the new commits, so how do you want to proceed for the PR? We can do it from my fork, or if you want it fron your fork, you can rebase and then cherry-pick my commit on jumbotron.

[ajnavarro]

LGTM