brian

joined 2 years ago
[–] brian@programming.dev 2 points 4 months ago (1 children)

yeah there isn't really a general purpose react way to do that.

if order didn't matter then you could just have a Header component that registers itself in a context but there's no way to know where each component is relative to its siblings.

the other way is to break out of react and just walk the dom. pass a ref to your component and use that as the root to walk. only works assuming normal react dom renderer and no portals.

you can combine those two options too, use context for registration so you can attach extra info, then dom for position.

there are some libs that let you walk a component tree, but they're all focused on ssr and idk how they work in a browser. wouldn't go this route for anything prod.

last option is just store your content as data. have md/mdx/json/whatever files that are the content for your page, then as you parse them build up the tree. probably the most robust if it fits your use case. if you use MDX it seems like they already have some solutions

[–] brian@programming.dev 2 points 4 months ago (3 children)

there's sort of ways to achieve this but none of them good react. what's the actual goal?

[–] brian@programming.dev 4 points 4 months ago

yeah that should just be a pip package instead, then install it any normal way

[–] brian@programming.dev 11 points 4 months ago (1 children)

the social pressure of other kids

[–] brian@programming.dev 1 points 4 months ago

I'd assume most people on minimal split keyboards use vim bindings or similar. that's what I usually do and I have a quefrency and wireless corne. I only end up using fn keys if I'm playing games. for programming I'd rather have mnemonic chords like <space> p c for project menu then compile instead of remembering f7 or whatever

on that note though, a quefrency might fit your needs. it has 8 fn keys on the side and the others on a layer. otherwise you can always get custom pcbs, it's work but it's not that bad

[–] brian@programming.dev 1 points 4 months ago

seems like everything. canonical has it listed as still evaluating. it requires you to open a url with emacs though, so shouldn't be that bad to avoid.

[–] brian@programming.dev 11 points 4 months ago (1 children)

most things seem to have settled on this, but tabs are so much better for accessibility. programmers with bad vision can have trouble differentiating smaller indentation levels, while some of them just bump the font size up so high that 4 spaces takes up too much screen space. each one can set a tab width that is comfortable for them. https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/ has some good arguments

with a forced formatter and a configured editor there really isn't any argument for spaces

[–] brian@programming.dev 2 points 4 months ago

alpine fits that, or derivatives like postmarketos

[–] brian@programming.dev 3 points 4 months ago

have you considered https://github.com/a-schaefers/systemE plus https://github.com/emacs-exwm/exwm ? that's basically an entire emacs userland

[–] brian@programming.dev 2 points 4 months ago (1 children)

4 to 5 added like 2 tags, but was fully backwards compatibile. the painful upgrade you're thinking of was 3 to 4 where they basically rewrote, it but don't have any tutorial content other than one of the main devs making an absurdly long series of walkthrough videos so it's impossible to find the topic you're interested in

[–] brian@programming.dev 0 points 4 months ago* (last edited 4 months ago)

json is fine as a serialization format for things that need to be text, but it's not great as something that gets edited by hand.

not that I enjoy xml, but writing long strings in json is even worse. xml I can write multiline strings as a first class entity.

I can add a comment to an xml document, json I have to write something hacky like "//": "my comment" and hope whatever is consuming it doesn't care.

there's just as many problems with json parsers, since most but not all of them treat numbers as js numbers, which are basically floats. you can't rely on an arbitrary consumer having support to parse ints above a certain size so you just have to make everything a string and hope.

json allows duplicate keys, but they get overridden by the last occurrence. you can't round trip json without losing something. you can't rely on just seeing a key value in json text and that being correct since there could be another later. doesn't come up often but it's there.

[–] brian@programming.dev 2 points 4 months ago (1 children)

trunk based development generally still merges branches into a main one, see this. idk if only using main even has a name

view more: ‹ prev next ›