# IofTV-Screen and what a Chinese data dashboard template inherits from its fork

> IofTV-Screen is a Vue 2 large-screen dashboard template built on DataV and ECharts, forked from the vue-big-screen project and reworked for map-heavy monitoring screens. Its documentation is written almost entirely in Chinese, its dependency set is from the Vue 2 era, and the last push was on 2026-05-13.

**daidaibg/IofTV-Screen** — 🔥大屏，物联网大屏，一个基于 vue、datav、Echart 框架的大数据可视化（大屏展示）模板

- Repository: https://github.com/daidaibg/IofTV-Screen
- Website: https://www.daidaibg.com/bigscreen
- Stars: 664 · Forks: 104
- Language: Vue
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/daidaibg-ioftv-screen

## A fork of a fork, and the documentation says so

IofTV-Screen is a big-screen template for the internet of things, built on Vue, DataV and ECharts, and the project description places it in a lineage rather than claiming to be original. It is modified from the open source framework vue-big-screen, and the README points at the original project as the base.

That lineage explains the shape of everything else, including the parts that would be strange in a project starting from scratch. The structure is the upstream structure, the component naming follows the upstream convention, and the README itself tells readers to consult the upstream documentation for the usage instructions, with a link to the original project's usage section.

There is a separate repository for the Vue 3 and Vite version, IofTV-Screen-Vue3, with its own GitHub and Gitee addresses, so the two codebases live side by side rather than one superseding the other.

The project is MIT licensed, the primary language is Vue, and the homepage is daidaibg.com/bigscreen, while the live preview and screenshots are at gaobug.com/bigscreen. The repository is not archived, and the last push was on 2026-05-13, with no GitHub releases. The GitHub and Gitee mirrors are both linked, which is a convention for projects with a Chinese user base, and the Gitee mirror is where a fork workflow is described in the upstream project.

The topics are datav, echarts and vue, which is the whole stack in three words.

## The README is written for a Chinese reader, and that is a real cost

The documentation is the first practical obstacle, and it should be weighed before the code.

The project description, the features list, the file table, the component API tables and the troubleshooting notes are all in Chinese. The links point at the Chinese-language documentation of Vue, DataV, ECharts and mock.js, several of them through a gitee link redirect rather than the canonical site.

For a reader who does not read Chinese, the usable information is in the code, in the file names, in the dependency list and in the handful of code examples. That is not nothing. The file layout table alone tells you what lives where:

| File | Role |
| --- | --- |
| main.js | main entry file, brings in the Echart and DataV files |
| utils | utility functions and mixins |
| views/ home.vue | the main structure of the project |
| views/ other files | the area components of the interface, named by position |
| assets | static resources, logos and background images |
| assets / css/ | common CSS files and global quick style adjustments |
| components/echart | all of the ECharts charts, named by position |
| common/... | globally wrapped ECharts and the flexible plugin code for screen size adaptation |
| api/api.js | the interface wrapper file |
| mock | simulated data endpoints |

The naming convention is worth noticing on its own. Components are named by their position on the screen, which is a sensible convention for a dashboard where a chart is identified by where it sits, and it means the structure of a new page is predictable if you follow the same rule.

So the honest characterisation is that this is a Chinese-language project with a Chinese-language documentation set, and an international user inherits the code without the guidance.

## The build is Vue CLI 4, Vue 2 and Element UI

The dependency manifest in the repository is the clearest statement of the project's era.

The scripts section is small and entirely Vue CLI based:

```json
  "scripts": {
    "serve": "vue-cli-service serve --mode dev",
    "start": "vue-cli-service serve --mode dev ",
    "dev": "vue-cli-service serve --mode dev ",
    "build": "vue-cli-service build --mode production",
    "report": "vue-cli-service build --report"
  },
```

The three development scripts all run the same command with different names, and the build script has a report variant that produces a bundle analysis. The devDependencies confirm the toolchain: @vue/cli-service at version 4, babel-plugin-component, sass-loader, mockjs and vue-template-compiler.

The runtime dependencies are where the design decisions live. @jiaminghi/data-view is the DataV component library at 2.10, echarts at 5.4, vue at 2.7.13, element-ui at 2.15, vue-router at 3.6 and vuex at 3.4. There is also vue-easytable for tables, axios for HTTP, and a set of build-time helpers: ejs, uglify-js, sass, node-forge and glob-parent.

So this is the Vue 2 stack, with the Element UI component library, and the same Vue CLI 4 scaffolding that a lot of Chinese Vue 2 projects from that period share. The browserslist targets more than 1 percent, the last 2 versions and not dead, which is a sensible set for an internal dashboard.

The three scripts in the README are the whole getting started process, npm install and then npm start, and the repository ships a .env, a .env.dev and a .env.production alongside vue.config.js and a .babelrc, so the dev and production modes are configured rather than implicit.

## Screen scaling is handled by a wrapper component with a wide API

The mechanism that makes a large-screen dashboard look right on an arbitrary display is the scale-screen component, and the README documents its API in a table.

The usage is a wrapper element with a width and a height, and the charts go inside it:

```vue
<template>
  <scale-screen width="1920" height="1080">
    <div>
      <v-chart>....</v-chart>
      <v-chart>....</v-chart>
      <v-chart>....</v-chart>
      <v-chart>....</v-chart>
      <v-chart>....</v-chart>
    </div>
  </scale-screen>
</template>
```

The props are the interesting part. selfAdaption is a Boolean defaulting to true, controlling whether scaling happens at all. width and height are the design dimensions, defaulting to 1920 and 1080, which is the standard 1080p canvas. autoScale takes a Boolean or an object with x and y, and when it is an object, x true produces a margin on the x axis and y true produces a margin on the y axis, and the config is ignored when fullScreen is enabled. delay is the debounce time for window resize events, defaulting to 500 milliseconds.

fullScreen enables full screen adaptation, and the README warns that it comes with a stretching effect, that autoScale is then ignored, and that it is not recommended unless necessary. boxStyle and wrapperStyle are Objects for changing the container style and the adaptation area style, following the Vue two-way binding style format.

The caution at the top of the section is worth repeating: the component uses the Scale approach and automatically adds overflow:hidden to the parent element. That is a behavioural side effect on the surrounding layout, not just a visual one.

The globals in the common directory described as globally wrapped ECharts and the flexible plugin code handle the screen size adaptation and are said to be customisable, which is where you would change the scaling behaviour if the defaults do not suit your display.

## Mock data is on by default, and turning it off is one line

The template ships with simulated data, and the README gives the exact way to remove it.

The mock entry lives in src/main.js and the line to comment out is the require of the mock directory, annotated with a comment asking whether to use mock. The instruction is that after disabling it you should connect your own backend interface.

That is the right default for a template, since a dashboard that renders nothing is a bad first impression, and it means the visual layout can be evaluated before any API exists. The api/api.js file is the interface wrapper, and the mock directory supplies the simulated endpoints that the wrapper calls, so the switch is a one-line change rather than a rewrite.

Two other small components are documented as additions on top of the upstream project, since the README says they wrap the few components the upstream does not provide. The first is a message notification component, written by hand because the author did not initially plan to use a third-party prompt library. It is registered globally in main.js so it can be used without importing, and the component currently supports only the warning type, with other types to be added as needed. The call takes a text and a type, and there is also a convenience form for the warning type directly. The table gives text as the prompt string and type as the popup type, with warning as the only selectable value and the default.

The second is an outer border component, written because the author's projects all had nearly identical borders and titles. It takes a title prop and wraps the content, and the README points at the file to change it if you want a different border.

## Scroll behaviour, the map and the branch you should pull

Three operational details in the README are the kind that save a day.

The first is the scrolling configuration. The project lets you configure whether content scrolls, and the README shows a settings button in the top right corner of the screen, with a screenshot of the resulting settings panel. You can also make the changes directly in code.

The second is the map data. The public directory holds a collection of map data, organised by city code, and the map component lives in indexs/center-map.vue. There is a control for whether the South China Sea is shown, through the isSouthChinaSea variable, which defaults to false, and the README notes that changing this value requires a page refresh. For a monitoring screen centred on a Chinese city, that map layer is a detail with a policy dimension, which is why the variable is named and documented rather than buried.

The third is the branch. The README says to pull the master branch, since the other branches are development branches. That is stated plainly and is worth heeding, because a screen that is going on a wall display is not the place to discover that you deployed a work in progress.

There is also a global filter for monitoring data items, which keeps two decimal places, applied in a template with the montionFilter filter, the name being what the project uses for it.

The project also asks for full screen display, with the F11 key, which is a basic requirement for this kind of screen and also a source of confusion when a display is managed by a kiosk system that has its own full screen handling.

## Where IofTV-Screen is the wrong tool

The first wrong case is a Vue 3 project. The Vue 3 and Vite version is a separate repository with a different build system, and the two do not share a codebase, so porting this template forward is a migration rather than an upgrade. The template also requires a full screen display, which is fine for a control room and wrong for a page inside an application.

The second wrong case is a project that needs a maintained dependency tree. The manifest pins Vue at 2.7, Element UI at 2.15, vue-router at 3 and vuex at 3, with a Vue CLI 4 toolchain, and the last push was on 2026-05-13 with no tagged releases. Vue 2 is at the end of its supported life, so every one of those pins is a liability rather than a convenience,.

The third wrong case is a team that does not read Chinese. The documentation set is the guide to the whole thing, and it is in Chinese, so an international team is reverse engineering the structure from the code and from a file table with no accompanying explanation of the layout logic. The upstream project it forks also documents in Chinese, so the fallback is no better.

The alternative worth naming is a modern dashboard framework, and the difference in approach is the whole argument. A current Vue 3 stack with a maintained chart library and a design system of your own gives you components you can rely on and documentation you can read, and it costs you the specific visual identity of this template, which is the thing that makes it attractive in the first place. DataV's border and decoration components are the reason a dashboard built on it looks like the ones in the screenshot, and that look is not reproducible from a generic component set without rebuilding it. So the trade is real: this template is the fastest route to a specific large-screen aesthetic on the assumption you will fill in the parts the upstream leaves to you, and the assumption includes reading the documentation in Chinese and maintaining a Vue 2 dependency tree by hand.

## Maintenance state, licensing and the shape of the community

The repository is not archived, and the last push was on 2026-05-13. There are no GitHub releases, so there is no version marker to pin against, and the version field in the manifest is 0.1.0 with the package marked private, which tells you the manifest is not the published artefact of a library but the manifest of an application skeleton.

The licence is MIT, with the LICENSE file at the repository root, so the fork, the modification and the use in a commercial product are all unencumbered, and the fork of the upstream project is licensed on the same terms.

The homepage points at daidaibg.com/bigscreen, while the README links to gaobug.com/bigscreen for the preview and the screenshots. The template's own README points at a separate site, gaobug.com/bigscreen, for the preview and the screenshots, so the deployment of the demo and the ownership of the project are not the same domain.

The community is a QQ group, with a two-group arrangement listed in the README where the first group is marked as full. That is the only support channel the documentation names, and it is a good illustration of the project's orientation. It is a template maintained in a Chinese community, published on two forges, documented in one language, and distributed through chat groups rather than an issue tracker.

The most useful thing a new adopter can do, given the documentation gap, is to read the upstream project's own usage guide, which the README points to twice. That document covers the parts the fork did not rewrite, and the fork's own README is explicit that the usage is largely the same.

## Conclusion

IofTV-Screen fits a team that needs a working full-screen monitoring dashboard quickly, on a map-heavy display, and that is comfortable reading Chinese documentation to fill in the remaining gaps. It is the wrong choice for a Vue 3 project, since the separate Vue3 and Vite repository is a different codebase with a different toolchain, and it is the wrong choice if you need a maintained dependency tree, because the manifest still pins Vue 2, Element UI and a Vue CLI 4 build. Before you start, read the file layout table, replace the mock data with your own API, and check the master branch, since the other branches are development branches.

## FAQ

### How do I start the IofTV-Screen dashboard template?

The README gives the two commands, npm install and then npm start, with the dev server served through vue-cli-service in dev mode. The project ships a .env, a .env.dev and a .env.production alongside vue.config.js, and the build script is vue-cli-service build --mode production.

### How do I replace the mock data with my own backend?

The mock is enabled in src/main.js, so you comment out the require of the mock directory, and the README notes that after disabling it you should connect your own backend interface. The interface wrapper lives in api/api.js and the simulated endpoints live in the mock directory.

### How does the IofTV-Screen template scale to different screen sizes?

The scale-screen component wraps the page at a design width and height, defaulting to 1920 by 1080, and scales the content. The README warns that it uses the Scale approach and automatically adds overflow:hidden to the parent element, and the global wrapped ECharts and flexible plugin code in common holds the adaptation logic.

### Which branch of IofTV-Screen should I use?

The README says to pull the master branch, because the other branches are development branches. The Vue 3 and Vite version is a separate repository, IofTV-Screen-Vue3, rather than a branch of this one.

### What licence is IofTV-Screen released under?

MIT, with the licence text in the LICENSE file at the repository root. The project is a modification of the open source framework vue-big-screen, and the README asks readers to consult the upstream project's documentation for the usage instructions.

## Sources

- [daidaibg/IofTV-Screen on GitHub](https://github.com/daidaibg/IofTV-Screen)
- [Issues](https://github.com/daidaibg/IofTV-Screen/issues)
- [License: MIT](https://github.com/daidaibg/IofTV-Screen/blob/main/LICENSE)
- [Project website](https://www.daidaibg.com/bigscreen)
- [README](https://github.com/daidaibg/IofTV-Screen/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daidaibg-ioftv-screen