search

inventree / InvenTree

Open Source Inventory Management System
https://docs.inventree.org
MIT License
4.32k stars 780 forks source link

Epic: React #3901

Closed matmair closed 1 year ago

matmair commented 2 years ago

This is an epic for https://github.com/inventree/InvenTree/issues/2789

Techstack Devtools:

Techstack UI:

Tasks:

Optional:

wolflu05 commented 2 years ago

Im definitely interested in this. I'm already experimenting with preact on my plugin as vanilla js is bad for reactive UIs.

wolflu05 commented 2 years ago

Is there also a plan for what tooling inventree will use (e.g. nextjs, vite, ...)? If you would go with create-react-app, I would definitely advise you to not do that, more infos. My first go would be nextjs or bundling with vite, which uses esbuild which is extremely fast.

If inventree won't use nextjs which has routing already implemented, I would consider using a much smaller package called react location.

matmair commented 2 years ago

@wolflu05 I have access to a sizeable private codebase that runs on the proposed stack; they used plain CRA, WebPack and nothing SSR so my plan is/was to use that as I know that works. Do you have production experience with the proposed packages?

The jsx-world seems to be very fast moving but I would prefer to target mature, battle-proven packages. I do not really fancy switching core parts out twice a year. We are essentially 2 devs right now.

wolflu05 commented 2 years ago

@matmair Currently I'm on the same point of making a decision what tooling I should use for my new app. I was always using cra in many of my latest projects.

Why not to use CRA

  1. Sometimes I needed extra webpack config so I used craco (package to modify hidden webpack config of cra without ejecting). But a month ago I thought why the hell should I use a package that is like a workaround around Bad native behavior.
  2. CRA is very heavy, it already has 300MB of node_modules if you just created a plain app.
  3. You said you want to target mature. Look at CRA the previous versions added polyfills for node API features to the browser. That is really bad behavior. CRA also sets really bad defaults for variables in js.
  4. I recommend looking a bit through the source code of cra it has tons of lines of code for all different user stories and edge cases, which is not very good. Lots of code means lots of things could break. You can see this on the number of issues (>1k). People really have problems with cra.

For more information I would really advise you watching some parts of this 1h video from Theo I linked in my previous comment.

Advantages of Nextjs

After all, I'm currently considering using nextjs or vite for my projects, but definitely not cra anymore. You can also use nextjs without any SSR, you can just export a static build like you can with cra. But nextjs has much better Code splitting between pages than cra. Cra is just one huge SPA where the client has download everything until it intially renders. Nextjs can split this into pages, so the client just needs to download the relevant code for the current page first.

One positive thing about Nextjs is SSR. I can really imagine using ssr for inventree. E.g. for social preview. Imagine some company using a Messager like slack and they share inventory. It would be really cool to have a simple social preview with the part title, image, ...

react location

I personally haven't tried react location jet, but it is looking really promising and it's from the same guy who made react query which I love btw.

Conclusion

I'm really looking forward that inventree switches to react. In the old issue you already proposed using nextjs. Very good decision in my opinion.

matmair commented 2 years ago

This issue was more thought to be a status tracker for me than a discussion as nobody stepped up to tackle this. If you are interested in developing we can talk about the stack though.

I worked with several internal projects that used nextjs in the last 6 months and we switched everything away from it. It was a dead dependency as we did not really use a lot of its features. We are purely a Django shop and we do not use SSR so I do not see a lot of benefit with it.

For InvenTree I would like to keep the deployment story the same as it is so no SSR either. Also no NodeJS on the user's server, just pre-baked assets that get shipped with updates. At that point, code-splitting also loses a lot of its appeal. Our user story mostly consists of heavy, returning users - we do not really need to optimise for the first load time as long as using it once the assets are there is snappy.

One positive thing about Nextjs is SSR. I can really imagine using ssr for inventree. E.g. for social preview. Imagine some company using a Messager like slack and they share inventory. It would be really cool to have a simple social preview with the part title, image, ...

No plans for SSR. The backend stays the same, Django is very capable of generating Open Graph images. Very easy to implement, with no need for SSR.

react location

Tbh I don't see anything useful that react router is not doing

I'm really looking forward that inventree switches to react.

That is far out at this moment, we have over a hundred forms, views and panels to switch over. Depending on how it goes this could also just ship as a plugin.

In the old issue you already proposed using nextjs. Very good decision in my opinion.

And Remix and Vue. If I was to choose an SSR framework I would use Remix.

matmair commented 2 years ago

@wolflu05 I played around with this a bit and the pipeline is much faster with vite. It is probably the right move. Do you want to take a look at the repo? I will do the implementation in phases in a separate repo for now.

wolflu05 commented 2 years ago

Cool that you found out that vite is much faster. This is one of the main key points of vite (Vite French for quickly). Also good that you considered to not use CRA anymore. Id be happy to take a look at your testing repo.

matmair commented 2 years ago

@wolflu05 I will ping you once it is ready to go

matmair commented 1 year ago

@wolflu05 not ready to really test rn but if you want to watch the progress getting there you can subscribe to this issue, I am tracking everything in more detail in that fork and also working on a beta website for gathering feedback.

wolflu05 commented 1 year ago

Thank you. I'll take a look this weekend and may propose some improvements.

wolflu05 commented 1 year ago

@matmair Do you also have an idea of how a panel mixin could work in the react ui? It would be really cool to be able to write panels with react. One idea which is currently already possible is using something like preact and htm.

matmair commented 1 year ago

@wolflu05 for now I am focusing on getting an MVP off the ground. I will think about plugins once the structure is proven

wolflu05 commented 1 year ago

@matmair Your base looks pretty solid from my view, but I have some comments on it:

  1. why are there two nested src folders?
  2. what about exporting optimized svgs (much smaller) from Inkscape for the served files instead of Inkscape svgs?
  3. what about grouping the pages in separate folders with its corresponding structural components (I guess this will be added later?)
  4. What about using something like prettier to enforce a standardized code style?

I only viewed the code for now. Would be cool if you can post some pictures somewhere for others to get impressions on how it goes without trying to run it

matmair commented 1 year ago

@wolflu05 thanks for the kind words.

  1. This is currently needed for a CI pipeline of mine that runs in a private context. Everything in the deeper src will be moved up one dir before release
  2. Good idea. I am mainly concerned with getting a functional product running right now - there is a bunch of backend work that needs to be done and I would like to get that all discovered and done in the next release cycle
  3. I am following a pattern that I saw at work, I will document more of that in the readme. Shared components are in components, route specific things are in pages - where nesting is possible if the components get complex
  4. See 2.

The beta branch is deployed to https://beta.invenhost.com and there are links to test deploys in all PRs in the repo https://github.com/invenhost/InvenTree/. I am building it up to be completely separate from the backend so that anyone can provide a different frontend that can be just used. Warning: This is still very experimental and no main views are merged into beta right now.

wolflu05 commented 1 year ago

@matmair Ok. Im already looking forward to it, when this will be merged 😀 . Just noticed one thing, while I was trying to check one thing. Where is your code? Is it gone?

matmair commented 1 year ago

@wolflu05 should be there again. Seems like my automation reverted to upstream by default

wolflu05 commented 1 year ago

@matmair ok. Good to hear. Sorry for double posting. I was very confused and thought I already posted this comment, but couldn't find it on my open tab after several reloads so I thought this is a bug with github so I posted it again :D . So now my question for later. Where do you prefer I should share my feedback?

matmair commented 1 year ago

@wolflu05 no problem. I made multiple PRs to inventree/inventree already. If it is ok with you I would prefer in invenhost/inventree. I will keep the issue quality low and everything moving very fast there. My goal for a finished MVP is KW 1/2 2023.

matmair commented 1 year ago

Closing this in favor of a smaller approach