Here to say that I have been working on a canvas-based app for a while now. Canvas apps are hard y'all!
I greatly appreciate tldraw and think the licensing changes are completely reasonable. The team is highly responsive on Discord, and looking forward to the company nailing down the nuances of pricing out this specific business model.
Pricing is difficult as it is, open source pricing double so, open source canvas library pricing has got to be one helluva hard problem to solve.
I would like to see more improvements to the sync portion, specifically more granular authorization controls.
I think that I'd prefer Firefox allow Bitwarden and other password tools to replace Firefox's password implementation. That way you'd get the UI/UX of integrated password management, but the single-source-authoritative backend too.
(before someone points out that Bitwarden has an extension: I do know that, but I'd like to see more modular features in browsers rather than our-way-is-best)
And it had way better UX when auto-fill didn't work, because for some reason about:logins doesn't work on mobile, so you have to hunt through a menu mess to copy the password manually from Firefox.
I continued to use it (because they didn't stop it syncing) until I switched phone and so couldn't easily install it.
Analytics should just be one point to weigh across others when making a decision. I don't fully think it's a binary decision to use it or not.
Consider analytics. Consider user feedback. Consider your gut. Consider stakeholder requests. Consider historicals. Consider your team. Consider your debt. etc etc
Different strokes for different folks, but frankly managers don't care if a deadline greatly encourages or greatly stresses their ICs. Either way, it's a way to hold people accountable for a deliverable at a certain date, or at the very least an update why it was missed.
Not having deadlines requires much more nuance to ensure a team delivers work consistently, and unfortunately nuance in work management doesn't report well
If you are going to do this it's best to advertise that fact in your job ads. You want people who like to operate in that atmosphere in return for something - promotion, perk or vision. Otherwise you just get high churn rate and poor productivity.
You should already be spinning up caches and databases in dev anyway?
I agree though that the article is missing some explicit insight into how this change is handled on the local dev environment. I'm assuming the local dev environment run commands were also updated to be these three commands, one per workload.
Basically, this distinction should be represented throughout all environments, dev/test/prod
You're translating the class-based way of working in React against hooks, without stopping to consider understanding hooks as a first-class principle instead of a translation.
It's called useEffect because it runs on the (side)effects observed by the dependency array. An empty array happens to happen on mount. useEffect returns a teardown function which happens to correlate with unmount when an empty array is passed.
It's called useRef because it returns a (mutable) reference that's detached from the reactive layer. The DOM element connection is just sugar.
I agree that useEffect has a lot of footguns, but this position seems very shallow. The whole pattern changed, it doesn't make a lot of sense to continue comparing the two
Yes, you're correct, and he got it wrong when talking about it.
This kind of goes towards my point. useEffect works, and it works great. It's flexible and powerful - but it's cryptic as hell, and the interface is just "memorize it because you have to", not something more intuitive.
What if useEffect required a 2nd argument, but you had the option to pass in self, which would still offer the onMount behavior, by mirroring the way the other form of it worked? Bada-bing, now there's no exception to the rule. What if the 2nd argument was a named argument, like "trigger"? Now it's self-documenting. What if the teardown function as an optional 3rd argument with a name, too? Now it's easy to glance at a useEffect and tell whether it's declaring a teardown without carefully reading the body. etc etc.
He says "useRef offering a connection to DOM elements is just sugar", but that's not sweet, to me. There's no reason one thing should do two totally different things. That's exactly what I'm complaining about.
In the beginning React was a great example of high payoff of just a little bit of "memorize it because you have to."
For many projects it felt like it gave you super powers, for some it was just OK, and a small percentage of interfaces just didn't fit the React model and were better some other way.
It appears to me that since then that small percentage has gotten the development attention (understandably), creating a React which is more well rounded and broadly useful but there is more to learn and the super power feeling has been dulled a bit.
Overall it has improved but I still wonder what a React that was more specialized for those interfaces where it really works great would be like.
I definitely agree useEffect is awfully cryptic and easy to get wrong, and I'm happy to be corrected... but I'm not sure how I'm wrong about it running on every render when there's no 2nd argument?
I kinda wish they'd made it easier to do the common operations like onMount and onUnmount by providing some simplified wrappers around useEffect (with less power comes less responsibility... or something). Of course we can make custom hooks for those, but having the well-trodden paths be paved is always nice.
I misunderstood what you were saying about it running on unmount when the dependency array is empty.
Of course, it does run on unmount when the dependency array is empty, and it runs on unmount when there are dependencies in the dependency array.
But upon re-reading what you said, I think your intent was that it's comparable to componentWillUnmount() in class-based React only when the dependency array is empty (because otherwise the cleanup function also gets called when dependencies change).
My apologies, as I never really used class-based React, so the distinction was lost on me (and also forgot about the cleanup function being called between useEffect callback calls)
Oh gotcha, no worries. I'm not sure if you meant to reply to me anyway, my comment was in regards to knodi123's original comment that linked to an article of mine and said it was wrong about when useEffect re-renders – but the comment was edited and that part is gone, so now mine looks entirely crazy haha.
I edited it because I realized I was wrong - I was confused by the difference between no 2nd argument, and [] for the 2nd argument. But again - as a full time professional web developer, who has being using React for a few years, I think that also goes towards my point. ;-)
useRef does only one thing. It returns an object where the latest value is current. That’s all. Element components will use a ref to put a reference to themselves if you pass one via the ref prop. They can be used to store anything else too. Nothing magic or confusing.
If anything it’d be weirder to make this two separate concepts. What would they even be? What does a ref not already do, as a box that contains an arbitrary value, that we’d want from a box with an element in it?
This is correct, but I think the point nickdandakis was trying to make is that useEffect does not directly correlate with componentDidUnmount because useEffect's returned callback could be called in the middle of the component's lifecycle, not only when the component unmounts.
Err.. no, you pass a callback (let's call it the effect callback) that returns a callback (the cleanup callback) to useEffect. The effect callback gets called when the component mounts, and when dependencies (if any) change. The cleanup callback gets called when the dependency unmounts (and will not be called at other times in the lifecycle)
edit: I'm wrong, the cleanup is also called when dependencies change, just not on mount.. eg. it gets called before the effect callback being called again.
In other words, the cleanup function is called on unmount when useEffect is called with an empty array, and if useEffect has dependencies, it will also be called when those dependencies change
It does, but it runs on more than just unmount when the dependency array is not empty. It runs anytime any dependency in the array changes. This is an important distinction. For example, event listeners added in useEffect will be removed anytime a dependency changes. Then a re-render will occur and they will be added back in the next useEffect body execution. This differs from componentDidUnmount which obviously only runs on unmount and never in the render cycle
yeah the article has a very US-centric take, stick shift is still very much alive in Europe. it's a lot of the times the more affordable option, and plenty of places in Europe dont have bumper to bumper traffic that makes stick a pain
The point is the same here though - electric cars don't have them, so it'll die out just as quickly (the fall off being even more precipitous). It'll be more missed here than in the states, where it sounds like it is already nearly gone.
This is the best summary of the topic I've read. Having used all three (submodules, monorepo, manyrepo) the only thing I can say with any certainty is - don't use submodules. The mono/manyrepo decision is not as clear cut but your description nails it.
Edit: submodules IS a viable solution for truly third-party repos over which you have no control and don't expect to ever edit.
Handsome is looking for a talented freelance frontend (or fullstack) engineer to work closely and collaboratively with our design team to create extraordinary, award-worthy website experiences.
The primary workload will be building out React pages (from Figma mockups) while contributing to our Design Library, and integrating REST APIs.
Technologies:
- React
- Node
- CSS Modules
- Babel, ESLint, PostCSS, Webpack
- Next.js
- Storybook
We are ideally looking for someone that has 3+ years of experience in the above (or similar) technologies.
Handsome is a digital experience agency. We work with the world’s most innovative brands to create digital products, services, and businesses that help them thrive in a progressively connected world. Our client partnerships include FedEx, Keller Williams, Dell, Facebook, Home Depot, Nickelodeon and others.
Shoot me an email at nick.dandakis[at]handsome[dot]is.
Handsome is looking for a talented freelance frontend (or fullstack) engineer to work closely and collaboratively with our design team to create extraordinary, award-worthy website experiences.
The primary workload will be building out React pages (from Figma mockups) while contributing to our Design Library, and integrating REST APIs.
Technologies:
- React
- Node
- CSS Modules
- Babel, ESLint, PostCSS, Webpack
- Next.js
- Storybook
We are ideally looking for someone that has 3+ years of experience in the above (or similar) technologies.
Handsome is a digital experience agency. We work with the world’s most innovative brands to create digital products, services, and businesses that help them thrive in a progressively connected world. Our client partnerships include FedEx, Keller Williams, Dell, Facebook, Home Depot, Nickelodeon and others.
Shoot me an email at nick.dandakis[at]handsome[dot]is.
I greatly appreciate tldraw and think the licensing changes are completely reasonable. The team is highly responsive on Discord, and looking forward to the company nailing down the nuances of pricing out this specific business model.
Pricing is difficult as it is, open source pricing double so, open source canvas library pricing has got to be one helluva hard problem to solve.
I would like to see more improvements to the sync portion, specifically more granular authorization controls.