Don't use DRY but WET: Write Everything Twice. :o)
In practice: The second time you implement something, start out by copy-pasting the first implementation. Once you're done with the second version, figure out if and how to abstract the two implementations.
Basically never ever abstract something if you only have two copies. Copy/paste and move on and be productive. It's usually only if you have a third or fourth copy that you start to see if there is any inherent abstraction to be gleamed.
The difference between PUT and POST is weather the command is idempotent or not.
Some APIs us PUT for creating items and let the clients specify the ID. If the IDs are UUIDs, the risk of creating duplicates is so slim that it's neglectable, and if that should happen, it's easy for the client to call again with a different ID. The real advantage of this approach is that if the API call times out, the client can just PUT again without having to fear creating a duplicate record. Recovering from a create with POST that has timed out can be pretty difficult because it can happen that the record was created just fine, but the internet connection died before the OK response reached the client.
Aren't you basically describing that you want idempotency?
The RFC 9110 (and also the old 2616) clearly state PUT is idempotent while POST isn't.
9.3.4 PUT
"The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server."
9.2.2 Idempotent Methods
"Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ."
I hope this means that CarPlay gets some more focus, because I would like a CarPlay integration where everything I have configured in a car is stored in a profile on my phone. This is what I imagine: When I get into a car, I just have to connect my phone, and the seat automatically adjusts, the radio has my favorite stations configured, and the UI is set up as I prefer it. When I find myself in a car model that I haven't driven before, the phone is able to make a good guess of how to configure things based on my setup in other cars.
> But you don't actually do that on Spotify. As the article correctly points out, your subscription fee doesn't go to the artists you listen to, it goes to the artists played on Spotify as a whole.
But doesn’t that even out?
Napkin calculations: There are 10 subscribers to Spotify, each paying 10 dollars/month, and everything goes 100% to the artist. 9 of them only listen to Taylor Swift and 1 only to Metallica.
If the subscriptions would go directly to the bands you listen to, Metallica would receive 10 dollars from the one listener.
But the subscriptions are distributed based on the percentage of listeners, meaning that the Metallica fan is only giving 1 dollar to their favorite band. But this percentage is also payed by the 9 Taylor fans, so they also pay 1 dollar. In the end Metallica receives 10 dollars per month.
Yes, I agree here. To me, this feels like the cookie legislation all over again, in the sense that the end result was a lot of annoying cookie banners instead of websites stopping the usage of cookies. And yes, I know that answering 'no' in these banners reduces the amount of cookies used, but I am seeing more and more websites where things like videos don't work unless you accept cookies.
> In the meantime current solution could stay simply because it does not hinder any competition.
As I understand it, this is specifically not allowed by the DMA, since it would be considered an unfair advantage to Safari, if that browser/engine was the only one allowed to run PWAs.
By the same logic the mere existence of Safari would be unfair because other browsers are not ported yet. This is of course incorrect reading of DMA. Have a look yourself:
If Apple demonstrates that the entry barrier is sufficiently low by cooperating with other vendors, how one could possibly build a legal case under DMA against them? On the contrary, by disabling PWA in Safari Apple acts as a gate keeper complicating access to the platform for business users. THIS is what DMA forbids.
Also it has to be taken into account that the less PWA engines exist the lower is actually the entry barrier. We only need 2-3 competing solutions max to support innovation without harming PWA developers.
It's my understanding that iOS is generally considered a more secure alternative than Android, and that part of this is the app review process, that is part of the App Store. So isn't there at least some truth in that opening this up will create a less secure environment?
I'll add again that while this may have been true at a point (and was covertly marketed into our brains by big apple) it's just not true anymore. It's honestly scary how often i hear this and yet almost no one can say where they actually heard it.
Maybe if you’re using a Pixel with the latest OS updates but the average person like my mom is using some off the shelf budget Chinese/Korean phone full of apps with spammy ads and confusing interface flows. The privacy settings are confusing and unlike my dad who comfortably uses his iPhone my mom has barely scraped the surface because the Samsung OS UI is such a mess (ie, 2 different messaging apps named Messages came preinstalled) and it’s slow, the UI with fonts scaled up for vision hides entire buttons in 3rd party apps (a joy to debug over the phone) etc.
Just this week she had to install a work app for scheduling from Googles Store and got duped into a fake clone that installed 4 other apps with repeated pop up apps emulating a signup wizard.
Those non standard androids are far far more worrying and the Google App Store is way less locked down.
If my dad was in the EU I’d have to tell him never to install an app using anything but the Apple App Store.
I went back to Spotify because I find the playlist there a lot better. I only tried Apple Music for a couple of months, when the service was released, so things could easily have changed.
The homepage (https://github.com/marketplace/watermelon-context) states that Watermelon supports "C, C#, C++ and 7 other languages", but I can't figure out what these other languages are. Has anyone found this info? Is TypeScript a supported language?
First: Realize that React Query isn't a library for fetching data, but a library for caching the fetched data. So think about how you will be invalidating that cache. For us, the rule of thumb was that each fetch to the API should have it's own cache key in React Query.
Second: The data in cached in React Query is effectively globally available, so it comes with all the benefits and pitfalls that globals have. We use Storybook and do not use React Query in the components that have stories, so React Query is only used in the root components of the app.
ReactQuery state is not global. It's set in a context, and it takes two lines to write a Storybook decorator that ensures a unique cache for each story.
It may still make sense to keep react-query out of your storybooks though.
In practice: The second time you implement something, start out by copy-pasting the first implementation. Once you're done with the second version, figure out if and how to abstract the two implementations.