My app currently uses Material-/ui v0.17.0 and in order for it to work with React v16.0.0 I have to upgrade to Material-UI v1.0.0.
I have seen the migration tool here. This just updates the import statements more or less. A lot of the props appear to have changed and are not backwards compatible. The tool actually would not work for me so
I manually updated all of my imports. It is almost looking like I have to rewrite the entire front end code of this app using the new updated v1.0.0 components. There has got to be a better way to do this. I understand that major version changes are "breaking" changes but this version upgrade may as well be an entirely new package. I cannot be the only person who has had to upgrade to v1.0.0 and am curious to how others have been able to successfully migrate over.
As you have noticed the API is not backward compatible and the migration guide is to be continued... I think there is a reason for that.
Although most of the components have their replacement, it looks like there is no straightforward way to migrate, especially because some components like autocomplete are not present in 1.x. If you heavily invested in restyling the components with touching the internals, you'll have even harder time, since in 1.x JSS is proposed way of styling.
The only way I see now is to rewrite it component by component. That's not something you'd like to read in the migration guide:)
For my specific project the solution seemed to be that I could use react v16.4.1 with material-ui v0.20.0. In doing so I had to drop react-tap-event-plugin which is not compatible with react versions >=16.4.0. This involved converting onTapEvent tags to onClick. Fortunately, by not having to upgrade the the new major version of material-ui, I did not have to update my components which was my fear.
All of this aside, I did spend some time converting material-ui components to v1.2.0 before I arrived at my solution which did not require these component modifications. When attempting to perform these changes, the documentation was sparse. I did find another Stack Overflow thread asking about the migration to v1.x.x here.
In that thread I linked to a couple of github issues that raised the same concern, and they are likely a valuable resource to keep your eye on if you yourself are trying to make this version transition.
[docs] 0.x => 1.x migration guide #7195
Codemod error when upgrading from v0.18.7 to v1.1.0 #11819
As well as some code someone documented when making the transition.
Here is a project where someone went through upgrading to mui 1.x.x from 0.x.x
Related
I am converting a vanilla project into react native and got stuck in this finding equivalent of navigator.bluetooth.requestdevice() in react native.
I have tried packages like https://github.com/innoveit/react-native-ble-manager but the problem is I have the code of that web project and finding this alternative can solve many tasks.
anyone who is trying to configure BLE in reacts native application but doesn't have a full idea about it let me give you a brief explanation as I was one of you.
There are not many packages out there with the maintained author so you have to rely on this https://github.com/innoveit/react-native-ble-manager package only or you have to get a response back from the natively build package by your self...
but not to worry because there aren't any major changes and its GitHub page is well-documented.
in my case, I was looking for a specific services id and Specific characteristic id to locate while looking for devices.. this package has serval events that can help you with it.. if you need detailed explanations please comment on this..
In the context of a TS monorepo, VS Code appears unable to track call hierarchies across libraries. I haven't been able to find a solution in repos based on yarn workspaces nor Nx.
I'm currently working with a micro frontend architecture; because components tend to straddle multiple libs, a typical call hierarchy trace gets maybe one component up, if that.
I have no issues with any of the standard cross-lib IDE features - auto import / code completion / inspection / yadda.
Is there a configuration setting I'm missing, or is cross-lib call hierarchies just beyond what's supported?
--
Update 11/09/22 - Still no luck on finding an answer to this. VS Code's docs have limited details on the call hierarchy feature. Perhaps I'll explore the feature API and see if there's any hints.
There is a medium-sized application written in Vue 2.7 (vuex, vue-router, etc.).
Until a certain point, we had SSR "with our own hands." Works crookedly and slowly, but works.
Recently, it has ceased to satisfy the needs of the project and we realized that we would be migrating to Nuxt.
Relatively recently, Nuxt 3 was released. It is now in rc state. We are betting on the further development of Nuxt. Therefore, we want to migrate to version 3. In addition, I think that in the near future we will consider switching to TypeScript, and in Nuxt 3 TS support is at a good level.
But there is an ambiguity: Nuxt 3 works with Vue 3. Also, it is recommended to use pinia instead of Vuex.
In this regard, questions:
Will most components work on Vue 2 when using Nuxt 3? I also want to move to Vue 3, but for now we want to speed up the process as much as possible. But I don't want to use crutches like "Vue 3 Migration Build" either.
Is Pinia definitively replacing Vuex? I mean, is Vuex going to be obsolete anytime soon?
Maybe there are more pitfalls that you should know BEFORE moving?
I would first off migration from Vue2 to Nuxt2, for the simplest + fastest approach without too many breaking parts. That way, you can at least benefit of some SSR capabilities until your whole migration is done.
Then, as Estus Flask said, the main issue would be the packages themselves (like Vuetify, which are still not fully Vue3 compatible in a stable state).
Also, you can totally migrate to Nuxt3 while keeping most of your components with the Options API (no need to refacto towards Composition API).
Nuxt3 is runnable in production but you may still need to troubleshoot it depending on what you are planning to use. Also, keep in mind that not all the modules are migrated yet, here is the latest roadmap.
So to answer your questions:
depending on how your components are now, you may need to update some of their parts, for further details you can check the migration guide and see if you are anyhow impacted by the changes when going from Vue2 to Vue3. If you want to iterate faster (and in a safer way), migrate to Nuxt2 first (should be quite fast!), then try to move towards Nuxt3
Pinia is better on pretty much all aspects when compared to Vuex. Will it be un-usable in the next 18 months? Probably not. It's still the official recommendation and will be the way to go overall (it's just better overall) but Vuex is still totally usable as of today. More details can be found here
as always, you gonna add a layer on top of Vue so it may impact several things:
depending on the amount of features you are using (Nuxt modules, Nuxt specific modules), some releases may take a bit more time overall to ship to production (using Tailwind with Vue3 was made possible earlier in comparison of Nuxt3)
Nuxt is a meta-framework, so it will bring some amount of complexity to properly understand all the Nuxt2 hooks, the way an isomorphic app works, how to use Vue2 packages, some gotchas etc... This is not coming from Nuxt itself, but more from the SSR part.
Nuxt3 is using Vue3, so you will need to then understand a bit more
how composition API works to get the benefit of using useAsyncData
composables etc... So the same work will be needed there too, hence why
I recommend a transition to Nuxt2 first. Of course, it all depends of
your team and if your members are already at ease with Composition
API
Overall, if you need a production-grade solution for your SSR needs, it will be quite useful to use Nuxt for sure but it will also require a bit of a learning curve.
You will also get quite some DX out of it, so that's a nice bonus!
Also, there is no real competition to Nuxt in Vue's ecosystem so at least, you don't need to fully compare meta-frameworks. AstroJS could be another approach but it goes out from the Vue ecosystem quite a lot overall (you won't benefit of Nuxt's modules/nice features for example) and solves some specific needs.
PS: Nuxt's team is working on the same approach regarding server-only components + heavy improvements regarding the hydration.
This question already has answers here:
React Native + React (for web) seed project
(6 answers)
Closed 4 years ago.
For a project, we need to have a Website and a mobile App (not a responsive Website) that both will consume my API. I used to work with React so I've checked a lot about React-Native for the mobile App part.
As I may understand, this require to create 2 distincts projects and it seems more efficient to do so (furthermore if these 2 projects don't share the same client). The problem is that, at a first look, both will use the same store... I don't want to dupplicate my store neither update both of them each time I update my API... The only difference I see between my React Website and my React Native App is the way they render. They will both have same functionalities. Can we go further by hypothesis that they will also share the same containers?
I try to open an issue on the github but they redirect me here to discuss about it.
So I want to know if you guys have THE best solution (clean & without bad surprises) to share code between React and React Native? If so, a tutorial will be very appreciate.
(Note: Searches were very time-consuming, React Native documentation should reserve a section about this subject...)
This was answered in this thread.
The overall idea is to have different entrypoints for each platform, and have the platform specific code (React for web and React Native for mobile) share common code like the Redux store.
An in-depth article can also be found in the thread I linked.
That being said, there are a number of tradeoffs and pitfalls to this idea one of them being dependency management, as you can see by this comment from the linked article:
I've just learned the shortcoming of this structure. By sharing a common package.json between native and web, you've glued them together by their common dependencies, the most important one being react. Let's say you upgrade to a version of react-native that depends on >= react#16, but your web app depends on some other library which depends on =< react#15. This exact thing has just happened to me, and I'm not finding an easy way out.
Another viable approach would be to transform the common areas of code into libraries you can export and import them to each separate project (mobile and web). That way you avoid the problems with the first option, but now you still have to maintain and update two separate code repos.
To answer your question the comments: I don't think there's anything wrong with having one project sharing code for both platforms, but it has to be planned very carefully so you won't break both your projects when trying to add new things. Try to start by planning your project structure so there's clear separation between web and mobile code and check if your dependencies are compatible with one another.
Here's a blog post that has an example project that should help you with designing your project.
EDIT: You could try React Native Web, but that's still in alpha so I wouldn't recommend it for work related projects (should be ok for school/personal projects though).
I want to build a basic app using react, flux (redux) and react-router. It will be a isomorphic (universal) app. I am confused about which react-router version should i use?
0.13.3 or 1.0.0-beta3.
Asking because 1.0 is cool and has better support for isomorphic apps and have simplified other things as well but it's still in beta.
Anybody knows when will 1.0 finalized?
Providing the module maintainers follow semver correctly then the following are some things you should be aware of when using a 0.x.x versus 1.x.x version.
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
In this case there is the added complication of the -beta3 which I would take to mean that the interface has been locked down but there may be bugs.
From the comments above, #Eelke is correct in that you may save time in the future by going straight to 1.0.0-beta3 but beware that you will be working with an unproven version.
My advice would be that if you're looking to put this into production in a critical application where you may need some support then stick with the 0.13.3 for now. If you have the time to 'go deep', dig around in the code (if you have to) and help the maintainers with feedback/bug reports then use 1.0.0-beta3