Recently, AS I am getting older, I like to think wildly. Some time ago, I suddenly thought of the possibility of implementing WYSIWYG in VS Code, so I finally made a plug-in that can achieve this effect after two months of hard work, as shown in the picture:

Support for real-time preview of React/Vue components in Webpack/Vite development (Angular should also be able to do this, but I haven’t used it yet, so I don’t support it).

use

Follow the reference documentation to install and use the plug-in: github.com/jaweii/Auto…

You can then preview the current component in real time as you write it:

Use cases for reusable components/materials can also be organized in a preview-specific file:

In the OUTPUT panel cut to AutoPreview to print debugging:

Breakpoint function: EMMM… ? I wish I had…

Drag the preview panel to the bottom to preview wider components:

implementation

At the beginning, I just wanted to implement Webpack+React component preview. I tried to implement it from Webpack configuration, but I found that this way was blocked because the dependency relationship was too complicated. After a few days’ use, I came up with the idea of remounting components in vue-Layout project. The preview can be implemented by asynchronously loading components of the current window file path through the import API provided by both Webpack and Vite and then remounting them into the preview window.

So it’s essentially the same thing as adding a route to your project to display the components in the current page, except the plug-in does it for you automatically.

Because of the import apis provided by both Webpack and Vite, all front-end frameworks can theoretically render project component implementation previews in VS Code when developing with both build tools.

extension

Right now I just wrote a couple of demos to test the effect of the plugin. I’m not sure if it will be useful or useless in the actual development process. I just did it for fun.

In the process of doing this, there are also some thoughts:

If previewable components are graded, then yes

  • Based on the component
  • Materials (combinations of basic components, elements, business logic, such as login boxes)
  • page

There are three levels.

Based on the component

Often in real projects, the underlying components are from internal or third-party component libraries, which are highly reusable and low-coupling, and provide documentation that can already preview the effects of the components. In-ide previews for such components do not seem to make much sense.

material

Materials are the combination of basic components, elements and business logic according to product requirements. Some of these materials are reusable within the project, some are not reusable within the project but exist across the project, and some are completely reusable by business customization.

In the coordination of actual projects, materials are also the easiest to be repeated, and as the project gets bigger and bigger, they will be scattered in each inner page. There is no display page to let different developers know which materials are already there, which will result in repeated materials. For this problem, development chain tools such as Ali Feibing and JD WORK are a solution. Their one-stop services of material production, release and use can largely avoid remanufacturing materials, which is a heavy weapon.

I think of a small weapons program, that is, for material preview in IDE, if reasonable agreement, use, may also be a solution to improve the problem of remanufactured materials. For example, the convention developers export previews of reusable materials, so that plug-ins can list all previewable components for other developers to browse, other developers before developing new materials, first in the preview list to see if there is reusable, if there is direct reference reuse or CV customization, do not write their own.

page

Page level is very low reuse, but the IDE preview H5 page is also a good experience, no need to switch between the browser and editor, a bit of wechat developer tools feel.

—-

And one more thing, if the component of the preview to optimize development experience, I think not because it can preview, but because of the force components the preview function, the author preview component, natural need to transfer the mock data component props, and mock data can be reference for themselves and other developers and CV, this is the code maintainability, A very important reason to reduce synergy costs.

And how much more fun it would be for other developers if the preview function could list multiple use cases for the component:

—-

(Suggestions are welcome)