Gathering detailed insights and metrics for mh-kpc
Gathering detailed insights and metrics for mh-kpc
Gathering detailed insights and metrics for mh-kpc
Gathering detailed insights and metrics for mh-kpc
npm install mh-kpc
Typescript
Module System
Node Version
NPM Version
JavaScript (68.21%)
CSS (28.42%)
HTML (2.43%)
TypeScript (0.94%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
MIT License
1,981 Commits
4 Branches
1 Contributors
Updated on Nov 05, 2019
Latest Version
1.2.0
Package Id
mh-kpc@1.2.0
Unpacked Size
19.24 MB
Size
5.48 MB
File Count
2,325
NPM Version
6.9.0
Node Version
10.16.2
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
10
92
目前市面上已经存在大量组件库,我们为什么还要造这个轮子呢?下面我们解释下这个组件库开发的动机。
随着公司业务和团队的壮大,我们很难统一全公司的技术栈,或者也没有必要统一全公司技术栈,但是统一 全公司所有产品线的设计和交互风格,却是很有必要的。众所周知,前端单页应用的开发无非基于3大框架: React/Vue/Angular。如果不同框架维护一套自己的组件库,一方面维护成本非常高,存在大量重复劳动力; 另一方面,即使大家都按统一的交互设计稿开发组件库,也很难保证各个组件库设计和交互的完全统一。 这就是我们开发KPC的目的,它存在的意义就是:同一套组件库源码适应不同框架,来保证不同技术栈所开发出来的产品 的风格统一(write once, run anywhere)
![]() IE / Edge | ![]() Firefox | ![]() Chrome | ![]() Safari | ![]() Opera |
---|---|---|---|---|
IE10, IE11, Edge | last 2 versions | last 2 versions | last 2 versions | last 2 versions |
1npm install kpc --save
1module.exports = { 2 ... 3 resolve: { 4 alias: { 5 'kpc': 'kpc/@css', 6 } 7 } 8}
1module.exports = { 2 ... 3 resolve: { 4 alias: { 5 'kpc': 'kpc/@vue/@css', 6 } 7 } 8}
1module.exports = { 2 ... 3 resolve: { 4 alias: { 5 'kpc': 'kpc/@react/@css', 6 } 7 } 8}
1import {Button} from 'kpc'; 2 3<Button>Hello</Button>
1<template> 2 <Button>Hello</Button> 3</template> 4<script> 5import {Button} from 'kpc'; 6 7export default { 8 components: { 9 Button 10 } 11} 12</script>
1import React from 'react'; 2import {Button} from 'kpc'; 3 4class App extends React.Component { 5 render() { 6 return <Button>Hello</Button> 7 } 8}
1npm install kpc-angular -S
webpack.config.js
Angular CLI 初始化的项目必须使用@angular-builders/custom-webapck
来配置webpack
1const path = require('path'); 2 3module.exports = function(config) { 4 config.module.rules.find(rule => { 5 if (rule.test.toString() === '/\\.css$/') { 6 rule.exclude.push(path.resolve(__dirname, 'node_modules/kpc-angular')); 7 return true; 8 } 9 }); 10 11 return config; 12};
src/app/app.module.ts
1import { KpcBrowserModule, KpcModule } from 'kpc-angular'; 2import { NgModule, CUSTOM_ELEMENTS_SCHEMA } from '@angular/core'; 3 4import { AppRoutingModule } from './app-routing.module'; 5import { AppComponent } from './app.component'; 6 7@NgModule({ 8 declarations: [ 9 AppComponent 10 ], 11 imports: [ 12 KpcBrowserModule, 13 AppRoutingModule, 14 KpcModule, 15 ], 16 providers: [], 17 bootstrap: [AppComponent], 18 schemas: [CUSTOM_ELEMENTS_SCHEMA] 19}) 20export class AppModule { }
1import { Component, ViewEncapsulation } from '@angular/core'; 2import { MessageComponent } from 'kpc-angular'; 3 4@Component({ 5 selector: 'app-root', 6 template: ` 7 <k-button type="primary" (click)="onClick()">Hello World</k-button> 8 `, 9 style: ` 10 .k-button { 11 margin: 10px; 12 } 13 `, 14 encapsulation: ViewEncapsulation.None, 15}) 16export class AppComponent { 17 onClick() { 18 MessageComponent.success('Welcome to kpc world!'); 19 } 20}
欢迎加入QQ群反馈问题和获得即时帮助,QQ群:529739732
性能损失非常小,因为兼容层并不会处理太多的东西,仅仅只是完成不同框架执行上下文的切换,唯一带来的损失 可能是框架需要引入兼容层和Intact底层库所带来的打包文件的增大,但只是增大了大概80KB(没有开启gzip)的体积, 相比目前前端项目动辄几M的打包文件,增大的并不多
如上所述,兼容层仅仅完成上下文的切换,本质上还是谁的元素谁去渲染,所以理论上能实现100%的兼容, 但目前考虑到项目中对各个特性的实际使用情况,并没有实现100%兼容,有些注意事项已在文档中说明, 如果对某个特性有需求,后面我们会逐步完善来达到100%兼容性
需要
node@10
以及npm@6.9
以上
1git clone https://github.com/ksc-fe/kpc.git 2cd kpc 3npm install 4npm run dev:doc 5 6# 测试 7npm run test 8# 更新测试快照 9npm run snapshot 10# 部署文档 11npm run deploy:doc 12# 发版 13npm run release
MIT
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 0/30 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no SAST tool detected
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
181 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More