Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

reload rules #898

Open
edenvidal opened this issue Jan 4, 2025 · 29 comments
Open

reload rules #898

edenvidal opened this issue Jan 4, 2025 · 29 comments
Assignees
@atulbhatt-system32

Comments

@edenvidal
Copy link
Member

edenvidal commented Jan 4, 2025 •
edited
Loading

  • when there's a change in the code like a new/removed node or a source inside an attribute has changed. need to test and improve.
  • when clicking the button or keyboard shortcut
  • ...?

experiment with way to smooth (fake) the reload so that it won't lose context
@edenvidal edenvidal converted this from a draft issue Jan 4, 2025
@edenvidal
Copy link
Member Author

@atulbhatt-system32 need your help with this

@edenvidal
Copy link
Member Author

@atulbhatt-system32 i think we clarified this in another issue?

@atulbhatt-system32
Copy link
Contributor

@edenvidal I think this part is more focused toward handling reload rules for active html file but we can have it grouped altogether.

@edenvidal
Copy link
Member Author

yes @atulbhatt-system32 i also think this part is actual kinda covered by kareem?

@edenvidal edenvidal moved this from Next Up to Idea in rnbw 0.1 Feb 3, 2025
@atulbhatt-system32
Copy link
Contributor

@edenvidal he implemented reload button with iframe reload which works correctly. Rest I'm not sure if all the other things are working correctly.

@edenvidal edenvidal moved this from Idea to Next Up in rnbw 0.1 Feb 3, 2025
@edenvidal edenvidal moved this from Next Up to In Progress in rnbw 0.1 Feb 3, 2025
@atulbhatt-system32
Copy link
Contributor

@edenvidal please add more detailed context to it.

There is files related reload in issue #892 and that's different.

Need a clarity on what actions we do and what results we observe. And what do you mean by fake relaod?

@edenvidal
Copy link
Member Author

@atulbhatt-system32 the reload action is partially implemented, so some of the checkboxes here are already completed. however, i’m keeping them all together to ensure the best possible user experience around reloading.

  • prevent full page reload unless strictly necessary, specifically enable when:
    • a <script> source (src attribute) is added, removed, or modified
    • a <link rel="stylesheet"> source (href attribute) is added, removed, or modified
    • a <meta> tag affecting page behavior (e.g., viewport, charset, refresh) is changed
    • the <body> or <html> tag is replaced or modified in a way that breaks the document structure
    • critical inline scripts (<script> without src) are added or changed
  • cache and restore selection state and scroll position
  • add a subtle loading indicator instead of a blank screen
  • maintain visual continuity during refresh (e.g., fade transitions)?
  • save and restore user selection state
  • preserve scroll position after reload
  • restore focus after reload
  • leverage existing morphdom for smoother dom updates
  • use the node tree event system to track and restore state
  • implement a "soft reload" mechanism for partial updates
  • ensure no white flash during content updates
  • maintain smooth visual transitions during reload
  • improve perceived performance
  • a/b test different transition approaches
  • coordinate with monaco editor state management if necessary

@edenvidal
Copy link
Member Author

@atulbhatt-system32 please, what are we doing with this one?

@atulbhatt-system32
Copy link
Contributor

@edenvidal

I was thinking about this only when I mentioned about the behaviour of phcode node updating dom when there are parsing errors.

To prevent full page reload we need to make sure we update only specific part of the ui for which the code has changed. If we are able to do that there won't be full page reload until and unless required.

Also I was trying to change morphdom with Idiomorph which I was able to do to some level. As Idiomorph also gives us control on how we treat head tag and if we want to preserve any node.

We also need to think about handling web-components.

I think if we are able to solve this - it will solve the bigger picture.

This issue is very broad in terms that it is connected with everything. But this can be the starting point.

@edenvidal
Copy link
Member Author

@atulbhatt-system32 thanks. i feel the same way. the lowest layer of the reload system is the specific, contextual changes happening in the moment. then there's the actual brutal reload which is somewhat this task. i believe both should be addressed together.

@atulbhatt-system32
Copy link
Contributor

atulbhatt-system32 commented Feb 19, 2025 •
edited
Loading

@edenvidal I'm working on this currently and on the way also making things more of a event based then state changes triggered. So we can simply dispatch an event if we want to do something.

Now we have to categorise the content changes event based on:
needs complete reload or can be morphed (soft reload)

There are following events that causes the changes in text content in the editor:

  • Typing in codeview
  • Background Sync
  • Performing elements actions [can be morphed]
  • Changing settings (adding attributes) [can be morphed]
  • Performing files actions

There might be more which I'm missing.

@atulbhatt-system32
Copy link
Contributor

I tried other libraries such as cheerio and rehype to see if we can get more helpful results from parsing. Rehype seems a good option from the point of extending functionalities.

https://github.com/rehypejs/rehype
https://github.com/cheeriojs/cheerio

Apart from that I am making an event which triggers when we open a file.

Currently our functionalities are linked based on effect of change in currentFileContent. We have to maintain a lot of other states to differentiate if the updates in currentFile are due to typing, edit/undo, or opening a new file which makes things complex.

I'm trying to make this also event based. Also I will try to update and simplify the nodeTree.

@edenvidal
Copy link
Member Author

thanks for the update @atulbhatt-system32 . would be good to stress-test it heavily with complex pages such as the rnbw.design or rnbw.design/guide while making this core update

@atulbhatt-system32
Copy link
Contributor

Yes @edenvidal.

This is a very core change so every single functionality will be required to best stress tested. With all this I'm aiming to simplify the APIs of rnbw too.

@atulbhatt-system32
Copy link
Contributor

atulbhatt-system32 commented Mar 5, 2025 •
edited
Loading

Here is the progress:

  • New NodeTree is implemented and updated throughout. But this lead to other changes required to be done.

  • A lot of redundant code was found along the way which was required but with states restructure and introduction of new states setup the logics became simpler.

  • Introduced a middleware before setting state where all the processing is done before that particular state updates are handled instead of using the useEffect.

  • Separated a lot of code into small small utils with independent roles and with much clear code.

  • A lot of functionalities that were related to designView are rewritten and simplified. Basically the flow of design view(iframe) actions is now much clear and this is also in progress. Some of them are done with syncing with nodeTree however syncing with codeview is left as codeview part is in progress.

  • Panel toggling is also simplified at logic level. The function to toggle them is now extracted to a util instead of tightly binded across the app.

Currently working on codeView.

  • In codeview the goal is to have separate models for separate files. I did a quick test for having a new model for each file type but it takes a performance hit. So I will either try to have new editor model for each file type(extension) or just 2 models one for the html files and the other for all the other file types.

  • Have to handle web-component opening which can be implemented after multi model is achieved. The code in codeView is also very confusing and have multiple flow which I will try to simplify.

  • In Codeview the mapping with source code also needs to be done for nodes to have sync behaviour so that we can have error free updates atleast for actions such as copy, group, duplicate, etc.

These are the current set of actions I'm doing. It will take time but will result in a more robust code. Coding it slow but consistently with thoughts.

@edenvidal
Copy link
Member Author

thanks @atulbhatt-system32 ! amazing. i am thinking, maybe break into smaller chunks what we can?

  • nodetree implementation
  • design view updates
  • codeview changes
  • web component handling?
  • can we benchmark?
  • test both model approaches separately?
  • utility structure
  • state management flow
  • architecture diagrams

would more frequent check-ins work as each piece is done? helps catch issues early. lmk your thoughts

@atulbhatt-system32
Copy link
Contributor

For nodeTree the logic to create tree is re-written and invalidNodes are not added to the tree instead of removing them later. Also the tree structure is now such that the complex-tree can easily use it without re-mapping the values.
Also now we are using maxNodeUid concept to create nodeUids for each node. Now if the update type is "morph" then we will try to give new added node new NodeUids which will be incremented value of maxNodeUid.

And once it was done all the places where nodeTree was getting used was updated to support the new format. Also, the logic to create tree is extracted out from react-hooks to our html service file which is below.

These are the html services where we have all the functions related to html file. We call these functions directly inside design view.
Image

Similarly there are other services I'm adding gradually. Like this global service:
Image

Regarding state changes, I separated the states that we had before and now created a new state called currentPageState.

Image

A separate state for editor. Here I'll add more. This way the isolation will be clear.

Image

Moved panel state to global as it is related to the entire app:

Image

Before the types and constants were scattered but they are now collected and imported from one file.

Image

Image

Regarding Web-Components handling, i.e. on double click of a web-component we open its file but we have to make sure that loading the web-component file doesn't affect anything on stage until it's saved or changed.

So with multi-model approach the goal is the same. Design view shouldn't be affected because of opening of file that are non-html files. But as the lot of things are connected with onChange of editor value so things gets re-triggered we need to separate this behaviour.

And at this stage itself we will try to implement the functionality that whenever any file is changed it refreshes/reloads the design view.

We can do all the testing once all the pieces are connected. As there won't be any perceived changes in what currently exists. However, the goal is to have robust code to reduce the leakage points for bugs and solving existing bugs. Yet also making sure it is easy to add new functionalities with as much clarity as possible.

Once the multi-model setup is done we can test both approaches. Multi-model implementation is simple at one step but the challenge is that we are overriding a lot of stuff in how editor handles things for html files which we don't want it to do it for non-html files. Such edit and undo are done based on nodeHistory for html files but we don't want the same behaviour in case of non-html files.

@edenvidal
Copy link
Member Author

thanks @atulbhatt-system32. continuing the discussion on the multi-model setup—the ability to interpret open-format files (literally text) with common models is amazing. it is the foundation of ai-native design environment

@atulbhatt-system32
Copy link
Contributor

Yes! what I'm thinking is to create the models for all types of files we have just after creating the file tree where we can easily know the type of files we have.

This way the model will be ready by the time we load the file of that particular type.

@edenvidal
Copy link
Member Author

amazing @atulbhatt-system32

@atulbhatt-system32
Copy link
Contributor

Basic level multi model implementation was done. However, faced with an error. Sometimes when opening different types of file the content of the current file is not shown however the model of the file gets updated.

The file apis are still confusing and going through the documentation of Filer to see how to handle the files effectively as the current code has a lot of chains and difficult to understand.

Till now only html files were handled with nodeTree. Now, starting to cover fileTree too.

This issue exists already in our project where switching between files sometimes shows wrong file content.

@edenvidal
Copy link
Member Author

thanks @atulbhatt-system32 ! what can i do to help/test? lmk

@atulbhatt-system32
Copy link
Contributor

@edenvidal Right now there are incomplete functionalities so you won't be able to test much. But today I will push the branch where I'm doing all the changes. So you can check it. There won't be any visible change.

@edenvidal
Copy link
Member Author

let's not look back. if you're confident there's no UI/UX impact, merge to dev in full force @atulbhatt-system32

@atulbhatt-system32
Copy link
Contributor

By the point where I said there won't be any visible change means the code I wrote and restructured won't show any effects on application.

Currently a lot of functionalities are not working as they are not connected.
After node tree restructure, I am restructuring file tree and it's APIs.

I have pushed a branch called: restructure-and-optimize

There all the current progress is there.

@edenvidal
Copy link
Member Author

@atulbhatt-system32 got it! So, the big question is—what’s the delta needed to run it smoothly? when do you think we can get there? 🙏

@atulbhatt-system32
Copy link
Contributor

@edenvidal To run it smoothly, every bit of code needs to be predictable in workflow. At least for me. If I'm finding a piece of code taking a lot of time to figure out. I'm breaking it down and segregating it.

Today I did a breakdown of rnbw init function.

I don't have a fix timeline for this milestone.

@edenvidal
Copy link
Member Author

@atulbhatt-system32 is there something we can hold on to? 🙏

@atulbhatt-system32
Copy link
Contributor

I will try to do it by or before 24 March

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@atulbhatt-system32 atulbhatt-system32

Labels
None yet
Projects
rnbw 0.1
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
2 participants
@edenvidal @atulbhatt-system32