As these are downloadable from npm with their names with different sizes. In which scenarios we must downloads tanstack react query and for which react-query.
As far as I can tell the author chose to publish the new v4 version on #tanstack/react-query whilst keeping the v3 version on react-query.
So most likely, you want the latest version, which is #tanstack/react-query.
This is detailed here: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4#react-query-is-now-tanstackreact-query
Related
My team has a monorepo written with React, built with Webpack, and managed with Lerna.
Currently, our monorepo contains a package for each screen in the app, plus a "container" package that is basically a router that lazily serves each screen. The container package has all the screens' packages as dependencies.
The problem we keep running into is that, by Lerna's convention, that container package always contains the latest version of each screen. However, we aren't always ready to take the latest version of each screen to production.
I think we need more granular control over the versions of each screen/dependency.
What would be a better way to handle this? Module Federation? peerDependencies? Are there other alternatives?
I don't know if this is right for your use case as you may need to stick with a monorepo for some reason, but we have a similar situation where our frontend needs to pull in different screens from different custom packages. The way we handle this is by structuring each screen or set of screens as its own npm package in its own directory (this can be as simple as just creating a corresponding package.json), publishing it to its own private Git repository, and then installing it in the container package via npm as you would any other module (you will need to create a Git token or set up SSH access if you use a private repo).
The added benefit of this is that you can use Git release tags to mark commits with versions (we wrote our own utility that manages this process for us automatically using Git hooks to make this easier), and then you can use the same semver ranges that you would with a regular npm package to control which version you install.
For example, one of your dependencies in your container package.json could look something like this: "my-package": "git+ssh://git#github.<company>.com:<org or user>/<repo>#semver:^1.0.0 and on the GitHub side, you would mark your commit with the tag v1.0.0. Now just import your components and render as needed
However, we aren't always ready to take the latest version of each screen to production.
If this is a situation that occurs very often, then maybe a monorepo is not the best way to structure the project code? A monorepo is ideal to accommodate the opposite case, where you want to be sure that everything integrates together before merging.
This is often the fastest way to develop, as you don't end up pushing an indeterminate amount of integration work into the future. If you (or someone else) have to come back to it later you'll lose time context switching. Getting it out of the way is more efficient and a monorepo makes that as easy as it can be.
If you need to support older versions of code for some time because it's depended on by code you can't change (yet), you can sometimes just store multiple versions on your main branch. React is a great example, take a look at all the .new.js and .old.js files:
https://github.com/facebook/react/tree/e099e1dc0eeaef7ef1cb2b6430533b2e962f80a9/packages/react-reconciler/src Current last commit on main
Sure, it creates some "duplication", but if you need to have both versions working and maintained for the foreseeable future, it's much easier if they're both there all the time. Everybody gets to pull it, nobody can miss it because they didn't check out some tag/branch.
You shouldn't overdo this either, of course. Ideally it's a temporary measure you can remove once no code depends on the old version anymore.
I am looking to optimise my React app and would like to use the profiler within the react dev tools Chrome extension.
I tried to use it and saw that it says:
which made sense as I was still on an older version of React at the time (16.1.4 I believe). So I have since upgraded a little to ^16.8.6 and built & deployed the changes to my environment, but for some reason I am still seeing the message indicating that I am on a pre-16.5 version... I'm not sure what is wrong.
Also, I have a local express server to build and render things locally, and that seems to have no issues whatsoever, and will let me use the profiler...
Is there something in my build that is keeping it on an old version perhaps?
In React Native apps, should you try to keep all libraries/modules on their latest versions? How do you approach this?
As per say, it's always better to upgrade the libraries frequently and use those libraries which are popular. Suppose you use an old library which uses componentWillMount and that's deprecated. So it may cause some sideissues in your app which you want be able to trace.
But as like ruain change, you should always look for the modules before updating, like react-navigation almost the complete flow is different in v5 and v4 , so you need to change your app flow and also test the whole app again. Similiarly in react-firebase v5 and v6 is totally differnt.
TL,DR: Yes , you should update , but after updating check all the changes in modules and test your whole app again.
Hope it helps. feel free for doubts
I try to migrate after a certain time, as the most recent ones always come with great instability.
An example of this is the new version of:
react-navigation
version 5
is not dealing very well with the react-native-cli version, but is getting along very well with the expo
I have problem with etcd v2. I am creating configuration management which is using etcd v2 as K/V store. Now I do need version history as well but looks like v2 does not support it at least not straight out from the box.
I have been reading their API and at least v3 do have version/revision in response. Is there any way I could get version into v2 response as well?
Only solution currently I find is to use custom suffix with version numbers. Also using running number (POST instead of PUT) but looks like it is more as ID than version (every new or modified will increase that number)
Any ideas? Custom database to store previous versions only proper solution?
Found out that v2 does not support versions (feature in v3). I created own logic to handle versions.
The current version of the Raven.Client.Authorization is back a version from Raven.Client. The new Raven.Clients allows you to use the latest Json.Net package and therefore RestSharp, ETC.
I hope to save some time / avoid a deep valley of frustration here. Can 1.0.972 support the 1.0.960 Authorization?
I don't sure if out of the box. Try use assembly redirect. If this is not working, you can get the source of build 972 from this branch than compile the Raven.Client.Authorization for yourself, after you update the json.net reference there.
P.S. If your app is in development and will be for the next 2 months, I strongly recommend that you'll try out v1.2, which already started the stabilization process.