DEV Community

Cover image for I made a vscode plugin that can write each part of React component in multiple split editors on the same screen

I made a vscode plugin that can write each part of React component in multiple split editors on the same screen

Joe_Sky on July 29, 2021

Hello, everyone! I'm a FE developer who had used React for more than 6 years, I prefer the combination of React + Mobx + CSS-in-JS. Most of my proj...
Read full post
Collapse
 
davispindola profile image
Spindola • • Edited

Really cool but to accomplish this solution you need to use jsx-sfc, it wouldn't be more easy to just use some kind of comment tagging, E.g.

// Splitt->Component
const YourComponent = () => {...}

// Splitt->Styles
const Wrapper = styled.div`...`
Enter fullscreen mode Exit fullscreen mode

This way your engine can splitt the editor into N blocks according the way you name each block. You can use more then just component, styles and render but also you can separate types, hooks, interfaces, functions and so on.

Collapse
 
joesky profile image
Joe_Sky • • Edited

Thank you~ I also think the comment tagging form is feasible. In fact, I have done some experimental thinking on how to adapt the idea of split editor to the normal React function component syntax. According to the way you mentioned:

// Split->Component
const YourComponent = () => {
  ...
  ...
  ...
}

// Split->Styles
const Wrapper = styled.div`
  ...
  ...
  ...
`
Enter fullscreen mode Exit fullscreen mode

Effect after folding:

// Split->Component
const YourComponent = () => {...
}

// Split->Styles
const Wrapper = styled.div`...
`
Enter fullscreen mode Exit fullscreen mode

If there is only one style component, this way will be very good. Let's try again, if there are multiple style components:

// Split->Component
const YourComponent = () => {...
}

// Split->Styles
const Wrapper = styled.div`...
`

// Split->Styles
const Section1 = styled.section`...
`

// Split->Styles
const Section2 = styled.section`...
`
Enter fullscreen mode Exit fullscreen mode

It looks like each style component is folded, but it takes up a little more vertical scrolling space. Therefore, it may be changed as follows:

// Split->Component
const YourComponent = () => {...
}

//#region Split->Styles
const Wrapper = styled.div`
  ...
`

const Section1 = styled.section`
  ...
`

const Section2 = styled.section`
  ...
`
//#endregion
Enter fullscreen mode Exit fullscreen mode

In this way, the scrolling space will become smaller after folding:

// Split->Component
const YourComponent = () => {...
}

//#region Split->Styles...
Enter fullscreen mode Exit fullscreen mode

I think if we can make a tool to automatically generate these comments with certain rules, it may be more natural. And it maybe needs careful design and thinking, with too many comments, some people also may find it redundant or ugly. A trade-off needs to be made between the visual beauty of the code and specific features.

Collapse
 
davispindola profile image
Spindola •

What about to read from the comment to the last line which includes an comment Split->${type} or it's blank, I was that it can be work as an visual "CLI" pra IDE, like using comments to tell the IDE how it should split their content

Thread Thread
 
davispindola profile image
Spindola •

If you agree, can we create a repository to develop this plugin to us from React ecosystem, also according the discussion above we can not only improve the experience of development for React dev but also for any JS dev at first moment.

Thread Thread
 
joesky profile image
Joe_Sky •

Well, this is really possible. The difficulty point in how to directly implement folding all the code which below the single line comment, native syntax does not support such folding. However "#region" is a native comment syntax that supports folding multiple lines.

jsx-sfc was not born for Split Editors at first, just like Vue's SFC, I just found it very suitable for the Split Editors, I think it can be used as an optional solution. Next, I will continue to try more purer solutions. But according to your idea, I prefer to implement it without comments if possible, I think the fewer additions may make this idea more acceptable to more people. Thanks.

Thread Thread
 
fijiwebdesign profile image
Gabirieli Lalasava •

I'm interested in building a generic solution from this. Not only react but a base for JavaScript.

We could grab the abstract syntax tree (AST) of the file and display a high level visual of possible split points of the nodes.

The user can customize per settings for each project/directory/file or AST node structure match. That would allow targeting React components, stores/models, other framework files etc. Or use defaults.

This way you can build custom configs based on selectors of the AST nodes or collections of nodes for different file types.

For example when viewing a class component extending React we know to apply react based AST selectors to split it. When viewing a MobX store we apply MobX splitting etc. Even create a plugin ecosystem around specific frameworks and selectors.

Thread Thread
 
joesky profile image
Joe_Sky •

It's a cool idea, I think it's feasible~

In fact, my solution is implemented by analyzing AST to find split points, and the original version of Volar is also implemented in this way. They just don't support configurable, but focus more on a specific framework.

My temporary goal is to use this idea to make a version that supports the regular syntax of React function components, it will still be placed in vscode-jsx-sfc. Because I hope jsx-sfc is more than just a special new API, and it can grow into a more generic solution focusing on improving the development experience of React function components. In the future, I will integrate more practical React development experience to design and optimize it.

If the community can create a general solution, such as vscode-split-editors, this is what I would like to see, which shows that this idea has wider existence value. I think we still need to design carefully. For example, we can't have too many split editors, if there are more than 4, each editor area is very small, which will also cause inconvenience. Thanks.

Collapse
 
joesky profile image
Joe_Sky •

Thanks for your reply~ I agree with you opinion that simplified and separated into smaller components is a very effective and popular practice, it's a great solution~ Let me explain a little, the ideas mentioned in this article do not conflict with splitting components:

1. Split editors can be regarded as a way to improve focus from the visual level, which maybe has no direct relationship with whether components should be simplified or separated into smaller components:

The left and right sub editors develop components and style code respectively, in my opinion, this is just a optional way to visually improve focus. For example, a small component is also applicable if it contains style code. This article is not intended to express that as long as we have split editors, we don't need to simplify and split components.

2. The jsx-sfc API can provide an optional new idea for simplifying and splitting components:

The normal way to split components is naturally the way you mentioned above, which is really great. But if you use the API of this article, you can split it like this:

import styled from 'styled-components';
import sfc from 'jsx-sfc.macro';
import logo from './logo.svg';

const Logo = sfc({
  Component({ styles: { Img } }) {
    return (
      <Img src={logo} className="App-logo" alt="logo" />
    );
  },

  styles: () => {
    return {
      Img: styled.img`
        &.App-logo {
          height: 40vmin;
          pointer-events: none;
        }

        @media (prefers-reduced-motion: no-preference) {
          .App-logo {
            animation: App-logo-spin infinite 20s linear;
          }
        }

        @keyframes App-logo-spin {
          from {
            transform: rotate(0deg);
          }
          to {
            transform: rotate(360deg);
          }
        }
      `
    };
  }
});

const App = sfc({
  Component({ styles: { Wrapper }, ...props }) {
    return (
      <Wrapper>
        <header className="App-header">
          <Logo />
          <p>
            Edit <code>src/App.js</code> and save to reload.
          </p>
          <a className="App-link" href="https://reactjs.org" target="_blank" rel="noopener noreferrer">
            Learn React
          </a>
        </header>
      </Wrapper>
    );
  },

  styles: () => {
    return {
      Wrapper: styled.div`
        text-align: center;

        .App-header {
          background-color: #282c34;
          min-height: 100vh;
          display: flex;
          flex-direction: column;
          align-items: center;
          justify-content: center;
          font-size: calc(10px + 2vmin);
          color: white;
        }

        .App-link {
          color: #61dafb;
        }
      `
    };
  }
});

export default App;
Enter fullscreen mode Exit fullscreen mode

Of course, this is just a way to manage a series of components in a single file. For a series of small components without reusability, if there are only a few, I prefer to manage them in a single file. The reason is that it can reduce some problems, such as repeated import or switching between many files (I often open more than 20+ tabs at the same time in vscode). However, even in this way, it still does not conflict with the idea of Split Editors, I also wrote the example in the article.

The above are some personal opinion, thank you for pointing this out~

Collapse
 
milkywayrules profile image
Dio Ilham D •

Wow, I like the idea, maybe will try this later. Sending you a heart first 👋👋

Collapse
 
joesky profile image
Joe_Sky •

Thanks! Wish this tool can be helpful to your work~

Collapse
 
newlegendmedia profile image
Jeff Hilton •

Has anyone created this kind of extension for Svelte? Svelte has very distinct sections of code, html, styles.