Thinking about ReactJS Refactor

[ajmcquilkin]

Hey all, I've been poking around within the frontend codebase (src/), and I'd love to discuss the idea of using ReactJS to handle the UI rendering within the application. I see that ReactJS is used within the documentation code (src/docs/), and I'm curious if there's a specific reason this isn't being used within the main application UI code. As projects start to get larger and more complex I find that working within a UI framework (ReactJS, AngularJS, VueJS) helps manage truth sources and avoid annoying bugs in a potentially much cleaner way, but if there's specific reasons why the project doesn't use such frameworks I'd also love to discuss those.

If it's of any use I've been exploring how this could look should this idea be considered further in this repository. In this specific repo I'm using a Tauri backend hosting a ReactJS frontend with Redux managing data transfer and caching b/w the frontend and Rust backend.

Cheers!

[kimlimjustin]

Thanks for opening this discussion, actually at first when choosing tech stack, I was once thinking about using either React, Vue, or Svelte for the frontend framework. but the key reason why I choose to use Vanilla javascript (or vanilla typescript per se) is because of the performance, remembering that Xploer used Electron before which is also consuming a high amount of resources. And even for now, I'm still not sure how the performance will go using one of the frameworks with Tauri.

I tried my friend project that is written in React wrapped inside Tauri and it consumes about 300 MB of RAM (not sure whether the program itself is not being optimized or it's the tradeoff of using React) while Xplorer only consumes about 150 MB of RAM for opening a directory (excluding file operation).

I'm also a fan of React, Vue, and Svelte and indeed it really boosts productivity for writing code, instead of manually creating elements, appending them, managing them, I can directly call the state change, however, at the same time, those frameworks consume a larger amount of resources than vanilla javascript does.

However, I'm open minded, if you can show me that using those frameworks won't affect the performance so much (what I mean by this is the tradeoff of using those frameworks is not too much) remembering that vanilla javascript indeed always gives me a lot of bugs, I can decide to refactor it.

I think this topic is quite interesting to discuss...

[kimlimjustin]

Your arguments make sense for me, and I tried your template and the RAM usage is quite ok although I'm still scared the RAM usage will rise after refactoring it, but the idea that this will boost productivity is indeed a good point.

Oh yeah, how about bringing CSS framework like tailwind CSS into Xplorer together with refactoring to React JS? I think it's really good for productivity tho.

Also are you willing to help with the migrating process? cuz I won't able to do the refactoring myself really soon (I'll have a test in two weeks and I need to study too) but still can help with.

Thanks

[ajmcquilkin]

Yeah that's definitely reasonable, since I don't think there's a great way we can imagine how large the memory usage would be until we try it. One thing we could do if we didn't want to fully commit to the change but wanted to try it out is to have a ReactJS feature branch that we work on in parallel with the main branch, and once that branch approaches parity with the master branch we can make the call on memory usage. I'm more than happy to initialize the refactoring process, although I don't think I'll be able to put in a huge amount of time within the next two weeks either. That being said, I should be more available after that point.

On the CSS point I personally like the SCSS flow we have going, although I don't have personal experience with tailwind. Do you feel there's a productivity issue around the current styling flow?

[kimlimjustin]

Yes, of course, we'll go by branching from master and merging the branch after everything is done. Do you want me to add you under the collaborator that you can freely push to the branch?

For tailwind, I was thinking that maybe it's good for automatically taking care about responsive, but I myself is quite ok to use either SCSS or tailwind tho.... How do you think bout it?

[ajmcquilkin]

Yeah sure, that would be awesome if you could add me to that branch.

For responsive development I personally find that if devs know even a small amount about responsive development (e.g. start at the smallest width for styling and add complexity with min-width queries) that it's easier to do "vanilla" (CSS or SASS), although that's just my personal take.
I can also code in some responsive layouts into the refactor and we can play it by ear from there?

[kimlimjustin]

Invited as a collaborator.

For the style responsiveness, indeed we all know how to handle that, but you know, sometimes people (or at least me) keep forgetting something (ex: forget to make an element responsive or something) and the CSS things is actually repetitive work tho... that's why, but yeah let just go with vanilla SCSS then, also when refactoring, please help to improve the layout if you found any broken layout if could.

Thanks a lot

[ajmcquilkin]

Update on this: code is being pushed here for the react refactor. I've been working on refactoring the data flow to support the updated react structure using redux and redux sagas to manage application side-effects. An initial version of this has been pushed that should be working, although I've not had the chance to rigorously test or document the code. I'll begin work on the react side of the refactor soon, although I would love thoughts on the initial data flow refactor if people have any.

[kimlimjustin]

Ye, I've noticed it for days but got no time to leave any comments, it seems good for me, maybe please try to migrate the open file and display files function first cuz that's the point to test the performance, however, I think the performance will be good as my assumption before saying that React consumes many RAM actually does not stands, since the point that makes the program consumes high amount of RAM is the streaming from Chromium (just discovered and reported this bug to Tauri) not React itself, but who really know until it's implemented

Also, don't forget to merge updates from the master branch before really working into it, there are some fixes and features implemented at the master branch and I think it's better to merge it before working to avoid confusion letter. I'll join into the refactoring process too later.

Thanks

[kimlimjustin]

Hello, I just realized when trying to help with the migration process that the thing if we use React, how should we implement some features like extensions, theme, etc? wouldn't it will become more difficult? any ideas about that?

[ghost]

Well, for Themes,
Usage of CSS Variables could be the way to go.
The current JSON gets transformed into a Stylesheet that sets the CSS variables and gets imported. In HTML, as long as all elements have the classes, the Stylesheet gets affected if they use CSS variables with a default value.

For extensions, that depends on what should extensions be capable of?

[gotjoshua]

Any further movements on this topic?

Preact or vue with unocss gets my vote

[kimlimjustin]

This pr hasn't has any update since then. I'm planning in restructure the whole code base, still thinking about the design tho

[gotjoshua]

Ooooo... I'd really love to think along for that restructuring! Is discord better? Or here?

[kimlimjustin]

Ooooo... I'd really love to think along for that restructuring! Is discord better? Or here?

I prefer discord