This is great!

[smuemd]

I find your wiki articles tremendously helpful. Thanks for taking the time to write these.

Are you planning on continuing the series?

Best, Stefan #

[pakx]

Stefan! Many thanx -- glad these are useful. I'd written these articles while I was discovering Mithril, and establishing patterns/practices for myself. It talks to Mithril's wonderfully small API-surface that just a few concepts later there's really not much more to say :-)

That said I should (and do intend to) complete at least those remaining items in the table of contents, and perhaps add a few more: CSS usage, mobile-first/responsive something, an intro piece on streams, but those go farther and farther away from Mithril-proper and are possibly less interesting. It's funny that the part that originally made Mithril attractive -- the possiblity of using 3rd party JS libraries/widgets easily -- turned out to be so simple it's been neglected thus far.

FYI what I'm working on now is a sample app, bigger than the mithril-hn-basic example -- mostly to convince myself that this structure is usable and scalable. As it happens I'm finding a few additional things to note down: e.g., fetching/displaying new data without jank, and setting up a larger project and toolchain.

BTW, have you been using Mithril long? Do you have usage patterns, that you find especially helpful? And do you have suggestions for considering aspects I may have missed?

Thank you for reaching out!

--pakx

[smuemd]

FYI what I'm working on now is a sample app, bigger than the mithril-hn-basic example --

Yes I read a comment of yours about this in the mithril gitter...

mostly to convince myself that this structure is usable and scalable.

... well you convinced me, for what its worth. but I am not a programmer, you see. But I was able to follow your steps, thought process and structure. Usually I get lost sooner or later with those things. Same is true for mithril itself. I didn't grok react and all the other. Just too complicated. But strangely I got mithril. I've been following mithril since the very early days out of curiosity, but never really used it until recently (got involved in a project where I have to build a bunch of web apps now). So your articles have been tremendously helpful in guiding these recent efforts

I opted for your basic-app structure over the Meiosis pattern, because I couldn't really see dramatic benefits with Meiosis, at least when using Mithril as the base lib.

Anyway, just wanted to thank you for sharing you patterns and experiences. It's very nice to meet you. I will be around.

-S

[pakx]

Stefan, ahhh, interesting, this "sev-commissioning" app of yours -- it always impresses me when apps we start out toying with actually end up doing something in the real world :-) What does it do? (Would you consider explaining in the readme?) BTW, the button + dropdown on this page -- is that from a widget library?

I assume by your comment of not being "a programmer" that you mean you don't do it as a profession. Certainly the code in the app above is clear and well organized, and even if you end up rearranging things, that's the sort of "refactoring" all code goes through. (Related, a quote I really like about writing in general applies just as much to writing software: there is no good writing; only good re-writing. :-) )

You seem to be further ahead than I in looking into authentication, setting up a toolchain, so if you write down your experiences there, do tell,

About Meiosis, I really like that pattern for its simplicity and power ... but "unfortunately" am still unable to find a compelling use for it -- something that our app-structure doesn't accomplish (when used with Mithril, as you said). Actually there is a use case I've found thus far -- fetching/showing new data without jank -- but given it's just that one case I'm tempted to find another solution. Incidentally, I should disambiguate: IMO the Meiosis pattern itself is simply the 3-6 lines that set up streams to manage model + rendering -- all the other view-creation business, model-part passing, etc, detailed on the Meiosis website are, to me, ancillary and not fundamental to the pattern itself.

(Nice to meet you, too, and many thanx for this chat!)

--pakx

[smuemd]

What does it do? (Would you consider explaining in the readme?) BTW, the button + dropdown on this page -- is that from a widget library?

Its colicated. The stuff you see online is vanilla Jquerie + bootstrap. This was hacked together by the backend architect. These are going to be converted to Mithril eventually. The site you where looking at is an interactive documentation of the sromdao business object. (https://github.com/energychain/StromDAO-BusinessObject) It's an interface to a boutique blockchain network for energy transactions that we operate. We run a small retailing utility here in DE on top of it as a testbed. But mainly we develop and govern the network itself. So the commission app will be used by one of our partners (a proper utility) as a way to manage commission payouts to resellers. Usually we wouldn't do these kind of high level client side stuff other than for demos. But it's early days and we gotta get the network started in terms of third parties using it as well... So here I am.

In terms of tooling I use spike (https://github.com/static-dev/spike). It's a static site generator around Webpack that comes with good defaults. Highly recommend.

On auth: the API used there is actually a wrapper around a server side deployed version of the business object. If you play around with it you will notice that the API is completely stateless even the auth... Maybe of interest for you. It's a pattern I have never seen before (I didn't design it)...

[pakx]

Thanx, Stefan, that was informative -- and indeed quite a bit of stuff going on, at least as far as business processes go!

I can see the API being stateless (fetchItem passes in all args needed for the fetch). And you seem to be using JWT ... which is also stateless, so to speak, but there's that whole matter of refresh-tokens, isn't there? That is, revoking tokens if necessary?

--pakx

[smuemd]

Well, the API is just an abstraction of a blockchain. So the Auth in reality is just public/private key management in disguise. So when you submit an ID and secret, the BO just creates and stores a private key on the blockchain node (server side). The token then let's you use this private key to sign your transactions in the network. And if you login with the wrong secret, you still get a token back. But it will be in read only mode. So no private key at play behind the scenes. Everything is fluid here...

This abstraction was created to reduce the crypto overhead when using blockchain tech and make the whole thing more compatible with traditional workflows.

[pakx]

Some of what you just said is lost on me (I haven't looked much into public/private key auth, etc), but I do remember seeing your comment that an incorrect secret would still get a read token. The "refresh token" issue I wondered about may apply here, too ... but I'll cross that bridge when I come to it :)