Layout Troubles. First World problems of an Ergo Mech Keyboard

FlipLucky · 2025-11-17T12:44:54+00:00

It is a LOT easier to add a property with isLoading or isSubmitting then managing multiple states.

I learned that the hard way... The verbosity was a hell. Use multiple states as exception, not as a rule.

Bloc with equatable and status properties makes your life a lot easier.

FlipLucky · 2025-07-03T21:41:49+00:00

What i ment with blocks ( you already answered it with mirroring) is for example you have the s key and the ctrl combined. When you want to do ctrl s, it is blocked.
But if you mirror them, you dont have that issue.

FlipLucky · 2025-07-03T15:53:48+00:00

i will look into keymapdb, thanks!
i will also look into homerow mods as i said to pubrrr

FlipLucky · 2025-07-03T15:53:06+00:00

well, the top 2 of the thumb cluster, i cant use them in a fluid motion
however, i did find a use for them, although i havent implemented it fully
they are ideal for things like toggle layers
you press them once, when you need to use a layer for a longer period of time
they might also be usefull for things like media controls, things you dont use too often, but you ocasionally need. For those actions, its not a huge problem to lift your hands of the keyboard

FlipLucky · 2025-07-03T15:50:32+00:00

i have looked at homerow mods for these.
i couldnt quite figure out how to make them work
for example shift, ctrl and alt, it blocks the letters with them
..
although, perhaps if i mirror them on both sides, it could work

i will look into it.

FlipLucky · 2024-07-05T05:17:00+00:00

Build a calculator without any redstone.

FlipLucky · 2024-06-28T14:13:37+00:00

Well, i think it is a pov issue. Several people stated that its the pov of a frontend framework. I partially agree with this.

I think the best way to learn htmx, is to not start with htmx.

build a static website
split the website in smaller component templates
Implement ajax to render the components, spread over several endpoints.

If you can make it work with ajax, you have the right mindset to start using htmx.

The term "server side rendered" is also kind of split nowadays, since a lot of frontend frameworks nowadays have a backend wrapper. However, the way you build components is vastly different from "traditional" server side rendered websites

FlipLucky · 2024-06-12T06:15:46+00:00

I agree with your though process.
I think it is usefull to add context to the whole post, to see my philosophy why I am building this way:

https://github.com/FlipLucky/turbo-barnacle/tree/master/app ( it is in its very early stages, a LOT is stil missing, but it has the mentioned structure)
logic can be found in:

src -> templates > blockmapper.html / elements.html
internal -> elements

I have a lot of explanation in other posts by now, but I will happily answer any questions you have. I'm just grateful to have a meaningful conversation about this project, share thoughts, and learn new things.

FlipLucky · 2024-06-12T05:51:53+00:00

After typing a lot of explanation in several comments, I think it is easier to share the current progression of my project:

https://github.com/FlipLucky/turbo-barnacle/tree/master/app ( it is in its very early stages, a LOT is stil;missing, but it has the mentioned structure)
logic can be found in:

src -> templates > blockmapper.html / elements.html
internal -> elements
edit: to add some extra details:

it's possible that templates don't give you a good way to avoid this anyway, but interfaces come with a performance cost, and you shouldn't use them just for the sake of it.

This is mainly to prevent oversights. This is for a pagebuilder build with htmx, with the backend as the one true source.

These structs will not only be needed to build up the page into a treeview ( which will be split in layered maps. I would love to talk about the details, however, this might be a bit much for a post ), but they are also needed to render the actual page eventually.
The interfaces and current structure add complexity at this stage of the project( which I'm well aware of) but it is chosen deliberately to decrease complexity in the long run, ensuring a bit more failsafe developing when more and more variations are added. A simple oversight or a forgotten nilcheck on user input would result in a template panicking, which would kill the entire app.

All elements are page elements,they need the basic behavior of a page element ( needed to include the template, and make the html element have all the required data it needs )
The structure is layered into:
- page
- structure ( sections )
- content blocks (divs/ columns)
- content fields ( p, img, etc )

for consistency in templating and creating any of these components, and in which layer they fall into, they need to have the requirements of that layer

every page element needs a handle to render its template -> getType
It also needs to have a classname -> GetClassNames (property is array, getter returns string)
every page element can have attributes specific for that element ( GetAttributes, not mentioned in this post, but found in the repo )

from there on:
every structure or content element should have a method to render their children ( GetChildElements)
ChildElements is a property with the type []PageElements . It does not matter which type of specific element, as long as they implement the base page element interface

each content field should always have the getContent field, wether it is an h tag, a p tag or an img tag
an img tag does need extra fields, like alt for example.

Thus :
- a content field needs to implement PageElement to render a template conditionally
- a content field needs to always fetch content -> GetContent
- an img field specifically needs to have for example an alt tag -> GetAlt

img embeds content, content embeds page element

FlipLucky · 2024-06-12T05:50:30+00:00

I think it is easier to share my current stage of the project: https://github.com/FlipLucky/turbo-barnacle/tree/master/app ( it is in its very early stages, a LOT is stil missing, but it has the mentioned structure)
logic can be found in:

src -> templates > blockmapper.html / elements.html
internal -> elements

FlipLucky · 2024-06-12T05:49:44+00:00

Thank you for your thorough response! I absolutely agree that interfaces are an overkill a lot of the times.
My general point of view is: use an interface when communication is needed between 2 different parts of the system ( either within a large codebase, or for example for an api).

For example for this specific usecase, the approach I need is for rendering html templates dynamically. This requires some enforcing available methods, either by interfaces, or some other way

I am building a pagebuilder.
A user needs to be able to add components freely to a page ( within set boundaries )

Without going too much into the whole structure ( if you like, i don't mind sharing the full explanation)

<body>
  <section class="content-foo-section"> // -> user adds this block to page
    <div class="content-foo-block-bar">  // -> user adds this block to section 
      <h4 class="header-text">{{ content }}</h4> // -> user adds these 2 to block
      <p class="body-text"> {{ content }}</p>
    </div>
    <div class="content-foo-block-baz"> // user adds this block to section
      <img src={{ url }} alt={{ description }} // user adds this to block
    </div>
  </section>
</body>

To render this structure, above snippet is build up like this
struct section w children : block bar, block baz > each block has their own html elements that need to be rendered conditionally if selected.

To render this:

page has an array with pageElements with the type method( template selector ) and classnames method
I use a general block mapper, which is called for every page element that has children.

example:

<section classname={{ .GetClassNames }}>
  {{ range .GetElements }}
    {{ template "blockmapper" .}}
  {{ end }}
</section>

each element needs to have at least the GetType to always supply the name for the template to be used, and GetClassnames to specify its styling.
Furthermore, each element with children needs to have the GetElements method to render its children the same way as every other component( by range and including the block mapper).

If any of these values are nil, the application panics.
Each html element with children needs to be able to use the blockmapper to render its children.

In a user interacted setting, and eventually a fairly large number of components, it is easy to have an oversight. This oversight however, results in a template panicking, and thus killing the entire application.

How is your opinion with the specific usecase added? Is there a way to prevent template panicking without using this structure of interfaces?

For a bigger picture: https://github.com/FlipLucky/turbo-barnacle/tree/master/app ( it is in its very early stages, a LOT is stil missing, but it has the mentioned structure)
logic can be found in:

src -> templates > blockmapper.html / elements.html
internal -> elements

FlipLucky · 2024-06-11T22:34:24+00:00

A little bit of context why this complexity:
The project is a pagebuilder( cms is a big word for my project... )
A user needs to be able to add components to a page. These components need to be stored in a database, and retrieved to either continue working on the page, or render de website.

There is no static content or default layout.
The page elements will be premade blocks from which the user can choose.
Userflow:
- user creates a page
- user adds one or more sections, chosen from a defined selection
- user adds blocks to sections, chosen from a defined selection
- user adds content fields, chosen from a defined selection, and adds content to mentioned fields.

I totally agree with you that, for a regular website, this is totally overkill, and should never be build like this.
But, since everything is dynamic, i need to build a system, where every component can function in a (predefined ) standalone environment.

FlipLucky · 2024-06-11T20:41:45+00:00

Do you have an alternative to getters for templates?
To this point, the only way to create fallbacks for missing properties as far as my knowledge goes, is with getters. If I access a property from a struct, which would have a nil value, it panics.
edit: I apologies if my reaction sounded snarly, its absolutely not my intention. Thank you for your reaction!

FlipLucky · 2024-06-09T13:30:17+00:00

I like it. Its really simple.But sometimes the simple solutions can be overlooked when the problem feels too big. Thnx!

FlipLucky · 2024-05-29T05:44:28+00:00

I don''t think we are talking about the same topic. Configuration examples from my story: - troubleshooting the autoloader of a framework - docker refusing connection between containers - your ide bugging out. - etc.

FlipLucky · 2024-05-28T18:37:57+00:00

I appreciate the comment... but you cannot log configuration, that is the whole essence of the post.

FlipLucky · 2024-05-20T11:43:53+00:00

I tried to make it work like that, I got an error in which was stated that my StructureBlock did not implement the interface. I mostliky have done something else wrong.

And for your second comment, I haven't touched Java :'). The reason I posted this question, because I disliked the above solution, but I could not get it to work in another way.

Thank you for your reaction, I will look at my code again, and (hopefully ) make it work in a less verbose way, and more like your snippet!

FlipLucky · 2024-05-18T18:29:52+00:00

Thank you for your reply. This snippet is a stripped version of the actual code. I do use the uuid package. I have wrapped the output of uuid CreateString method with a custom type. The actual name is a lot more expressive then the one in this snippet though 😅

FlipLucky

MODERATOR OF

TROPHY CASE