Same here. In fact, I took it one step further and drafted a document that outlines all the important business contacts I have the she would need to contact in case of my death. To liquidate assets, and/or help with keeping the businesses I have running. Online services, hosting providers, etc.
To be trained as a carpenter while being paid, more likely. Like the coding bootcamps that “graduate” you and then rent you out. If there’s no skilled labour. You have to create your own.
Speaking purely about web software / web APIs, most software is 90% CRUD. It absolutely makes sense to use a framework to save new hires from grokking 90% of it's capabilities. You can have a new developer do stuff right out of the gate.
In general, yes, but beverage intake results can vary a lot based on behavioral factors. If one frequently drinks sugary beverages or even alcohol to attempt to sate a hunger drive (e. g., due to leptin resistance), it could dramatically reduce intake of those things. But if intake of those beverages are driven by other factors such as poor judgement in beverage selection for hydration or alcoholism, it's not likely going to result in much of a change.
As far as medical solutions go, something like naltrexone is probably a better fit for discouraging unhealthy food/beverage selection, especially (but not necessarily) when paired with bupropion. The combo dramatically blunts the positive neurochemical effects of eating artificially sweet/salty/fat foods + drinking alcohol (and nearly eliminates the perceptible benefits of alcohol as well - it's a very surreal experience).
Do you mean .value when writing a component that's some sort of form field? How do you refer to that value in Svelte components?
edit: oh nvm, we haven't upgraded our codebase to Vue 3 yet, there are a lot more ".value"'s if you click through to the Vue 3 examples in the original post.
Vue has `refs`, which are reactive proxy objects that are used for tracking things like re-rendering.
Since vue does not hide the fact that something is a ref, you need to call `myRef.value` to get to the underlying value of `const myRef = ref(10)`.
In a new and currently experimental syntax, you can use `const myRef = $ref(10)`, at which point you can just use `myRef` directly. This will then be converted by the Vue SFC compiler.
Another option is to use a reactive object as the state: `const state = reactive({ myVal: 10 })`, at which point you can just use `state.myVal`.
In vue 2, objects are made reactive with getters/setters, so changing a field on an object can be tracked. That still exists in vue 3, but a separate api was needed for primitives like numbers or strings, without a parent object that they'be set to. Vue3's solution is to wrap it in a wrapper object called a ref, and to read it's value you have to use .value. It's a pretty simple concept.
In svelte, top level variables are automatically reactive.
Yes! This was exactly what I felt was more "natural" in Svelte.
I also like Svelte's "writable store" model rather than React's Redux which forces data to flow a certain way, through the dispatcher.
Svelte Stores make it a little too easy to "shoot yourself in the foot" if you're not too careful though, as you can make data bi-directional, and you can make children set parent data. This makes prototyping super easy and fast, but probably creates massive code readability problems down the line, especially for larger teams.
These days in reactland, you can easily get app-wide state using useContext (which is much MUCH simpler to work with than Redux). It's just a global store (well, or you can limit it to a certain part of the tree) that any child or sibling can read/write to at will.
But just like you said, it can be a footgun if you're not careful.
FWIW, Redux and Context are different tools that solve different problems, with some overlap.
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state _you_ are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
Thanks for sharing. I think you touch on some of the more powerful features of Redux (middleware, selectors, pass by reference instead of value, etc.)
But IMHO a lot of that is overkill when your only goal is global state. Context solves that problem very nicely (in conjunction with state and reducer, yes, but context is the big piece there). Prop drilling was a major hurdle to global state management. But redux introduces its own overhead (Flux architecture, actions and dispatches, etc.) that are unnecessarily complicated for simple state sharing.
I feel like the article spends a lot of time differentiating the specifics of use Context vs state vs reducers, but it kinda misses the bigger point... that using those is often enough and can remove redux, leaving you with more readable and less overengineered code. Redux might be the right choice for really complex states, but it's a pain to work with day to day. Context makes it super simple by comparison.
I see people ask on a literal daily basis "does Context replace Redux?". So, I was trying to make a few points in that post, mostly clarifying common misconceptions, because the question itself is rooted in some major misunderstandings about what these tools even _do_ in the first place:
- that Context doesn't "manage" anything by itself, and definitely not "state"
- That there are significant technical differences between the combo of `useReducer` + `useContext` and Redux/React-Redux, in terms of render performance, data access, and usage patterns.
- That this means there are also different use cases for those tools as well.
I wouldn't use Redux to maintain state for a form or isolated chunk of the app, I'd use context + `useReducer`. On the flip side, if I do have "global" state, I would pretty quickly switch over to putting it in Redux instead.
Yeah, except... the technicalities make it seem like no, but in reality use context CAN replace redux a lot of times. The power of redux is often unnecessary (or just gets in the way, really), and context is enough.
Your post makes it seem like they are wildly different when in fact they often meet the same need. Use context is helpful precisely because it can replace redux in many situations.
It doesn't really matter how different they are under the hood. Redux is often used only as a global store of state, and context makes that much easier... even globally.
Maybe redux is good for some edge cases, but otherwise it's just overengineered bloat. Context is much more elegant and intuitive. There's no reason to force yourself to use the Flux pattern if you don't have to. I'd certainly never add redux to a project unless I absolutely needed to, it's such a pain...
I'm talking about reactive references in the composition API; the options API is too different from Svelte to make a direct comparison. You can use reactive() to hide some .value's but they are more limited and I personally avoid them. There have been proposals to add more transformations to @vue/compiler-sfc to make refs more "magical" like Svelte.
