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.

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

Refactor code in EditorStore to separate out logic for FormMode and TextMode #1898

Merged
merged 2 commits into from
Mar 16, 2023

Conversation

gayathrir11
Copy link
Contributor

Summary

How did you test this change?

  • Test(s) added
  • Manual testing (please provide screenshots/recordings)
  • No testing (please provide an explanation)

@changeset-bot
Copy link

changeset-bot bot commented Feb 10, 2023

🦋 Changeset detected

Latest commit: 002fa85

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 28 packages
Name Type
@finos/legend-application-studio Patch
@finos/legend-extension-dsl-diagram Patch
@finos/legend-graph Patch
@finos/legend-application-studio-bootstrap Patch
@finos/legend-extension-dsl-data-space Patch
@finos/legend-extension-dsl-mastery Patch
@finos/legend-extension-dsl-persistence-cloud Patch
@finos/legend-extension-dsl-persistence Patch
@finos/legend-extension-dsl-service Patch
@finos/legend-extension-dsl-text Patch
@finos/legend-extension-format-morphir Patch
@finos/legend-extension-store-flat-data Patch
@finos/legend-extension-store-relational Patch
@finos/legend-extension-store-service-store Patch
@finos/legend-application-pure-ide Patch
@finos/legend-application-query-bootstrap Patch
@finos/legend-application-taxonomy-bootstrap Patch
@finos/legend-manual-tests Patch
@finos/legend-application-query Patch
@finos/legend-application-taxonomy Patch
@finos/legend-application Patch
@finos/legend-extension-format-graphql Patch
@finos/legend-extension-format-json-schema Patch
@finos/legend-query-builder Patch
@finos/legend-application-studio-deployment Patch
@finos/legend-application-pure-ide-deployment Patch
@finos/legend-application-query-deployment Patch
@finos/legend-application-taxonomy-deployment Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@finos-cla-bot finos-cla-bot bot added the cla-present CLA Signed label Feb 10, 2023
@gayathrir11 gayathrir11 changed the title Refactor code in to separate out logic for FormMode and TextMode Refactor code in EditorStore to separate out logic for FormMode and TextMode Feb 10, 2023
@codecov
Copy link

codecov bot commented Feb 13, 2023

Codecov Report

Merging #1898 (002fa85) into master (645c331) will decrease coverage by 0.02%.
The diff coverage is 30.09%.

@@            Coverage Diff             @@
##           master    #1898      +/-   ##
==========================================
- Coverage   40.32%   40.30%   -0.02%     
==========================================
  Files        1444     1447       +3     
  Lines       65971    66016      +45     
  Branches    15492    15494       +2     
==========================================
+ Hits        26601    26607       +6     
- Misses      39268    39308      +40     
+ Partials      102      101       -1     
Impacted Files Coverage Δ
...tudio/src/components/editor/aux-panel/Problems.tsx 7.40% <0.00%> (-3.31%) ⬇️
...nts/editor/command-center/ProjectSearchCommand.tsx 66.66% <0.00%> (+2.15%) ⬆️
...ponents/editor/edit-panel/FileGenerationViewer.tsx 7.69% <0.00%> (ø)
...rc/components/editor/edit-panel/FunctionEditor.tsx 14.34% <0.00%> (ø)
...ditor/edit-panel/GenerationSpecificationEditor.tsx 11.56% <0.00%> (ø)
...components/editor/edit-panel/GrammarTextEditor.tsx 17.02% <0.00%> (ø)
...src/components/editor/edit-panel/RuntimeEditor.tsx 18.08% <0.00%> (ø)
...itor/edit-panel/data-editor/EmbeddedDataEditor.tsx 17.24% <0.00%> (ø)
...s/editor/edit-panel/diff-editor/EntityDiffView.tsx 22.50% <0.00%> (ø)
...itor/edit-panel/mapping-editor/MappingExplorer.tsx 66.66% <0.00%> (ø)
... and 36 more

Copy link
Contributor

@akphi akphi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The interface makes sense to me, just left some minor comments on further cleanups we can do.

I haven't reviewed in-depth movement of code logic in EditorGraphState.ts and GraphEditModeManagerState.ts - I assume you just moved over code logic, if that's the case, nothing much to check there I think.

My concern is with the switchMode we do in GraphEditorModeManagerState, to me that the fact we need a source mode and the target mode seems unnecessary and can be simplified

@akphi akphi added Application: Studio Issues related to Legend Studio application Type: Refactor labels Feb 16, 2023
@gayathrir11
Copy link
Contributor Author

I agree having source mode and target mode in switch mode currently doesn't make much sense as we know what to do when we are entering a garph edit mode. But when we have multi file support knowing source mode and target mode is useful as the set of operations we do is different.
Let us assume if we want to switch to form mode, the set of apis we call would be different when we are in single file text mode and multi file text mode. I don't want to do bunch of if-else here again to know what mode i am in currently. I hope this reason is not trivial.

@gayathrir11 gayathrir11 force-pushed the refactor branch 5 times, most recently from b655d41 to 88d411c Compare February 24, 2023 11:44
isGraphBuildFailure: true,
}),
);
if (this.editorStore.isInFormMode) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to mention, the biggest thing about this task is that we must remove isInFormMode and isInTextmode from EditorStore, those methods should not be needed, we should add methods to the interface everywhere we see differentiating behavior like this.

Copy link
Contributor

@akphi akphi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some minor comments, like last time, the one thing that gates me from fully accepting this change is the complexity in switchMode(); like any function of this type, if we can break it into consistent, simple interface function call that would be great, from my perspective, changing mode is an operation that is used by higher-level code that has no knowledge of the mode implementation, what we're doing here is practically leaking of mode-specific logic.

Now, the only 3 places we should allow this sort of thing to me are:

  1. When switching mode since we have to explicitly mention the mode to switch to
  2. When displaying the mode switcher button (maybe, right now we have binary-state button, but if we have a dropdown or selector, this can even go away)
  3. When we initialize the mode in EditorStore or so, we are biased since we have to pick a default

{editable && editorStore.isInGrammarTextMode && (
<GrammarTextEditor />
)}
editorStore.graphEditorMode.mode ===
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not so satisfied with this, but we can deal with this later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see my comment below for ProjectViewer

@@ -64,7 +58,8 @@ const ProblemItem = observer((props: { problem: Problem }) => {
</div>
{problem.sourceInformation && (
<div className="auxiliary-panel__problem__source">
{editorStore.isInGrammarTextMode &&
{editorStore.graphEditorMode.mode ===
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

potentially if we have a place in rendering code layer to handle differentiating codepath, this is a good candidate to add there, together with all places we have to use editorStore.graphEditorMode.mode since although we decompose well at the state layer, our rendering is still messy

),
);
} catch {
yield flowResult(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note, here we're making assumption we're already in form mode, what if we're not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function gets called only when we initialize studio. So the mode we are in would be FORM

import { LegendStudioTelemetry } from './LegendStudioTelemetry.js';
import { GraphEditorMode } from './GraphEditorMode.js';

export class GraphEditFormModeState extends GraphEditorMode {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--> FormGraphEditMode, also rename the file

import { GraphEditorMode } from './GraphEditorMode.js';
import { ElementEditorState } from './editor-state/element-editor-state/ElementEditorState.js';

export class GraphEditSingleFileGrammarModeState extends GraphEditorMode {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--> SingleFileGrammarGraphEditMode (also rename the file)

@@ -1187,11 +894,73 @@ export class EditorStore implements CommandRegistrar {
);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably can move these 2 methods to inside of EditorGraphState now

@@ -169,8 +134,8 @@ export class EditorStore implements CommandRegistrar {
sdlcState: EditorSDLCState;
graphState: EditorGraphState;
graphManagerState: GraphManagerState;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, in terms of organization at EditorStore level, I think we should move EditorStore.graphEditorMode to EditorStore.graphState.mode, I want us to start thinking about how we organize this. Maybe, what we should do is extending GraphManagerState and have LegendStudioGraphManagerState or something and put all graph handling logic of EditorGraphState in there, but colocating GraphEditorMode with EditorGraphState is sensible as it is what we had before

const graphEditorMode = new GraphEditSingleFileGrammarModeState(this);
try {
yield flowResult(
graphEditorMode.cleanupBeforeEntering(fallbackOptions),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we still calling different set of methods when switching mode? I felt like we can also following a fix procedure, i.e. simplifying this down to bare-bone mode-independent logic, i.e.

attempt to leave and cleanup current mode
check if we can enter target mode
initialize target mode
switch to new mode

this.localChangesState = new TextLocalChangesState(this, this.sdlcState);
*switchModes(
to: GRAPH_EDITOR_MODE,
fallbackOptions?: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can sleep on this for now, worst case, we have different set of methods: handleGraphBuilderFailure() and handleCompilationFailure()

Copy link
Contributor

@akphi akphi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like said, let's address comments here in a later PR, the organization benefit we got out of this PR is already huge. Thanks @gayathrir11!!

@akphi akphi merged commit cc0030d into finos:master Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Application: Studio Issues related to Legend Studio application cla-present CLA Signed Type: Refactor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants