Conversation
|
Great news! I do not think I have many good reasons and I think it is fine if you keep some of them sprinkled around. One weak reason is that with nbRawHtml you increase the number of templates and blocks used (wrapping the container is a +1 over n contained, wrapping a standard block is a +2 on top of 1). On the specific of that column template, it seems it could be an alias for a NbDiv that could be part of nimib itself (with maybe also |
That's a fair point. The reason we wanted to reduce them was that we were hitting the maximum global variables limit with large presentations. But that shouldn't be a problem anymore as most blocks have a func rawHtml*(nb: var Nb, content: string) =
let blk = newNbRawHtml(html = content)
nb.add blk
template nbRawHtml*(content: string) =
nb.rawHtml(content)Previously all blocks defined multiple global variables. So we should be much better off now. It would still be a bit slower to build more blocks, but the most important ones that are used everywhere (
That is a great idea! I'll implement it right away! That could be useful in all sorts of situations :O |
@pietroppeter It's long due but I have managed to rewrite a large part of nimiSlides to use the new nimib version. The ones we were most interested in was
slideandfragmentCoreas they are now container blocks.Everything is not ported yet, there is still a lot of
nbRawHtmlsprinkled around everywhere. And for good reason, it's so damn easy and convenient 😅. So I'm not sure if it's worth the effort to define a new block type for each one. Take for example:It would translate to this code roughly:
It is not that much code, but there are a few of them. I mean, I should port them over but I'm just lazy. Can you remind me of a good reason why I should do it and then I'll do it? 🤣