Same problem here. I have Wave Keys for Mac, and my girlfriend has the Wave Keys for Windows with reversed Fn and Ctrl. It’s a headache when I go to her place. I use Karabiner, but it doesn’t really swap them, and Logi Options+ doesn’t either obviously.
I agree with Epic. It should be like on windows or macOS where you can register, get notarized, and then distribute without scare screens. I don’t see why phones are inherently different than computers.
I don’t want to be too flippant, but I think there is a real trade off across many aspects of life between “freedom” and “safety”.
There is a point at which people have to think critically about what they are doing. We, as a society, should do our best to protect the vulnerable (elderly, mentally disabled, etc) but we must draw the line somewhere.
It’s the same thing in the outside world too - otherwise we could make compelling arguments about removing the right to drive cars, for example, due to all the traffic accidents (instead we add measures like seatbelts as a compromise, knowing it will never totally solve the issue).
> protect the vulnerable (elderly, mentally disabled, etc)
Yes, one could imagine some kind of mental test and if you fail you don't get to use your bank online, you have to walk to the physical location to make transactions. But this can obviously be abused to shut out people from banking based on political and other aspects. Generally democracies are wary of declaring too broad sets of people as incapable of acting independently without some guardian. Obviously beyond a certain threshold of mental incapacitation, dementia etc. it kicks in, but just imagine declaring that you're too easy to influence and scam and we can't let you handle your money,... But somehow we can rely on you using sane judgment when voting in elections. Or should we strip election rights too?
We rely on polite fictions around the abilities of the average person. The contradictions sometimes surface but there is no simple way to resolve it without revising some assumptions.
The new direction isn’t Liquid Glass, but a more unified branding across Android and iOS. WhatsApp, Google Maps, Instagram, Netflix, Prime Video, and many others don’t look dated, because they don’t make heavy use of the older iOS design language at all.
The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.
And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.
The idea is that the component's API is not the DOM. Usually this means your data should flow in a certain way: top-down.
Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.
You don't usually read a component's state from outside (here: the "checked" property).
Instead you define an API where data only flows top-down.
When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.
The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).
"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.
When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).
But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.
This makes it easier to connect it with other components in a tree.
For example:
HTMLInputElement.checked can be true without a "checked" attribute being in the markup.
If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.
If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.
And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).
You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".
The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.
Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".
Input elements and reflected attributes such as "checked" are already a relatively complex case.
And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).
reply