- Dec 2023
-
werd.io werd.io
-
https://werd.io/2023/doing-it-all
Interesting to see what, in generations past, might have been a gendered (female) striving for "having it all" (entailing time with children, family and a career) has crossed over into the masculine space.
Sounds like Ben's got some basic priorities set, which is really the only thing necessary. Beyond this, every parent, especially of new babies, in the W.E.I.R.D. culture is tired. By this measurement he's doing it "right". What is missing is an interpersonal culture around him of extended family and immediate community of daily interaction to help normalize his conditions. Missing this he's attempting to replace the lack of experience with this area by reaching out to his online community, which may provide a dramatically different and biased sample.
Some of the "it takes a village" (to raise a child) still operates on many facets, but dramatically missing is the day-to-day direct care and help that many parents need.
Our capitalistic culture has again, in this case of parenting in the W.E.I.R.D. world, managed to privatize the profits and socialize the losses. Here the losses in Ben's case are on his physical well-being (tiredness) and his mental state wondering if his case is "normal". A further loss is the erosion of his desire for a family unit and cohesion of community which the system is attempting to sever by playing on his desire to "have it all". Giving in to the pull of work at the expense of family only drives the system closer to collapse.
-
- Oct 2022
-
stackoverflow.com stackoverflow.com
-
that's right, we don't want to do params = { ... } because then we're hardcoding the implementation and it becomes very coupled. The benefit of doing it like in my examples is that you can change the method signature and still automatically capture all keyword parameters.
-
- Sep 2020
-
github.com github.com
-
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
-
Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
Tags
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
- ugly/kludgey
- explicit interfaces
- maintenance burden
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- Svelte: how to affect child component styles
- being explicit
- burden
- forking to add a desired missing feature/change
- workarounds
Annotators
URL
-
-
github.com github.com
-
The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
Tags
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- flexibility
- Svelte: action (use:)
- pass-through arguments/props/options
- extensibility
Annotators
URL
-
-
github.com github.com
-
Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
-