前端vue项目中遇到的难点（在vue项目中遇到的最大的困难）

本篇文章给大家谈谈前端vue项目中遇到的难点，以及在vue项目中遇到的最大的困难对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、前端开发的难点到底在什么地方？
• 2、VUE-PC端项目遇到的坑总结
• 3、Vue在前端开发中需要注意什么
• 4、前端开发过程中遇到过什么困难？
• 5、前端开发的难点到底在什么地方

前端开发的难点到底在什么地方？

个人觉得难点在浏览器的兼容上和技术理念的更替。前端技术的迭代一点也不比后端慢，从原生css+js开发，以前你会css和js就可以写前端，到现在react，vue的全家桶框架开发。前端的开发理念和技术主流已经发生了质的变化。es5，es6、es7规范的迭代也是前端的必备。加上webpack，nodejs等各种技术。前端现在早已不是以前会css和js就能满足的了。已经开始?自己的技术生态，未来也将蓬勃

VUE-PC端项目遇到的坑总结

其中说到跨域的话首要的就是axios的配置

主要原因是后台使用的是Multipart数组接收，vue这边使用的是formdata，红框一定要这样写，我被坑了好久，并且传输文件类的时候，不需要设置contentType，由于我用axios共同全局设置了这个 'Content-Type': 'multipart/form-data' 之后导致浏览器解析的时候，没有这个boundry（见图），最后还是用了vue-resource中的http解决的

由于后台不让前端带上角色和权限之类的信息，全部从后端拿数据，导致前端必须全部配置好所有的路由，通过后端返回的菜单信息filter出自己的菜单信息后显示

想要刷新页面就是这方法吧，挺好用

refreshPage() {

      location.reload()

    }

场景：比如商品详情数据，依赖路由的params参数获取的(ajax写在created生命周期里面)，因为路由懒加载的关系，退出页面再进入另一个商品页面并不会运行created组件生命周期，导致文数据还是上一个数据。

解决方法：watch监听路由是否变化

watch: {

  '$route' (to, from) { //监听路由是否变化

    if(this.$route.params.id){//是否有id

      //获取数据

    }

  }

}

Vue在前端开发中需要注意什么

基于Vue官方风格指南整理

一、强制

1. 组件名为多个单词

组件名应该始终是多个单词的，根组件 App 除外。

正例：

export default {

name: 'TodoItem',

// ...

}

反例：

export default {

name: 'Todo',

// ...

}

2. 组件数据

组件的 data 必须是一个函数。

当在组件中使用 data 属性的时候 (除了 new Vue 外的任何地方)，它的值必须是返回一个对象的函数。

正例：

// In a .vue file

export default {

data () {

return {

foo: 'bar'

}

}

}

// 在一个 Vue 的根实例上直接使用对象是可以的，

// 因为只存在一个这样的实例。

new Vue({

data: {

foo: 'bar'

}

})

反例：

export default {

data: {

foo: 'bar'

}

}

3. Prop定义

Prop 定义应该尽量详细。

在你提交的代码中，prop 的定义应该尽量详细，至少需要指定其类型。

正例：

props: {

status: String

}

// 更好的做法！

props: {

status: {

type: String,

required: true,

validator: function (value) {

return [

'syncing',

'synced',

'version-conflict',

'error'

].indexOf(value) !== -1

}

}

}

反例：

// 这样做只有开发原型系统时可以接受

props: ['status']

4. 为v-for设置键值

总是用 key 配合 v-for。

在组件上_总是_必须用 key 配合 v-for，以便维护内部组件及其子树的状态。甚至在元素上维护可预测的行为，比如动画中的对象固化 (object constancy)，也是一种好的做法。

正例：

ul

li

v-for="todo in todos"

:key="todo.id"

{{ todo.text }}

/li

/ul

反例：

ul

li v-for="todo in todos"

{{ todo.text }}

/li

/ul

5.避免 v-if 和 v-for 用在一起

永远不要把 v-if 和 v-for 同时用在同一个元素上。

一般我们在两种常见的情况下会倾向于这样做：

为了过滤一个列表中的项目 (比如 v-for="user in users" v-if="user.isActive")。在这种情形下，请将 users 替换为一个计算属性 (比如 activeUsers)，让其返回过滤后的列表。

为了避免渲染本应该被隐藏的列表 (比如 v-for="user in users" v-if="shouldShowUsers")。这种情形下，请将 v-if 移动至容器元素上 (比如 ul, ol)。

正例：

ul v-if="shouldShowUsers"

li

v-for="user in users"

:key="user.id"

{{ user.name }}

/li

/ul

反例：

ul

li

v-for="user in users"

v-if="shouldShowUsers"

:key="user.id"

{{ user.name }}

/li

/ul

6. 为组件样式设置作用域

对于应用来说，顶级 App 组件和布局组件中的样式可以是全局的，但是其它所有组件都应该是有作用域的。

这条规则只和单文件组件有关。你不一定要使用 scoped 特性。设置作用域也可以通过 CSS Modules，那是一个基于 class 的类似 BEM 的策略，当然你也可以使用其它的库或约定。

不管怎样，对于组件库，我们应该更倾向于选用基于 class 的策略而不是 scoped 特性。

这让覆写内部样式更容易：使用了常人可理解的 class 名称且没有太高的选择器优先级，而且不太会导致冲突。

正例：

template

button class="c-Button c-Button--close"X/button

/template

!-- 使用 BEM 约定 --

style

.c-Button {

border: none;

border-radius: 2px;

}

.c-Button--close {

background-color: red;

}

/style

反例：

template

button class="btn btn-close"X/button

/template

style

.btn-close {

background-color: red;

}

/style

template

button class="button button-close"X/button

/template

!-- 使用 `scoped` 特性 --

style scoped

.button {

border: none;

border-radius: 2px;

}

.button-close {

background-color: red;

}

/style

二、强烈推荐（增强可读性）

1. 组件文件

只要有能够拼接文件的构建系统，就把每个组件单独分成文件。

当你需要编辑一个组件或查阅一个组件的用法时，可以更快速的找到它。

正例：

components/

|- TodoList.vue

|- TodoItem.vue

反例：

V

ue.component('TodoList', {

// ...

})

Vue.component('TodoItem', {

// ...

})

2. 单文件组件文件的大小写

单文件组件的文件名应该要么始终是单词大写开头 (PascalCase)

正例：

components/

|- MyComponent.vue

反例：

components/

|- myComponent.vue

|- mycomponent.vue

3. 基础组件名

应用特定样式和约定的基础组件 (也就是展示类的、无逻辑的或无状态的组件) 应该全部以一个特定的前缀开头，比如 Base、App 或 V。

正例：

components/

|- BaseButton.vue

|- BaseTable.vue

|- BaseIcon.vue

反例：

components/

|- MyButton.vue

|- VueTable.vue

|- Icon.vue

4. 单例组件名

只应该拥有单个活跃实例的组件应该以 The 前缀命名，以示其唯一性。

这不意味着组件只可用于一个单页面，而是每个页面只使用一次。这些组件永远不接受任何 prop，因为它们是为你的应用定制的，而不是它们在你的应用中的上下文。如果你发现有必要添加 prop，那就表明这实际上是一个可复用的组件，只是目前在每个页面里只使用一次。

正例：

components/

|- TheHeading.vue

|- TheSidebar.vue

反例：

components/

|- Heading.vue

|- MySidebar.vue

5. 紧密耦合的组件名

和父组件紧密耦合的子组件应该以父组件名作为前缀命名。

如果一个组件只在某个父组件的场景下有意义，这层关系应该体现在其名字上。因为编辑器通常会按字母顺序组织文件，所以这样做可以把相关联的文件排在一起。

正例：

components/

|- TodoList.vue

|- TodoListItem.vue

|- TodoListItemButton.vue

components/

|- SearchSidebar.vue

|- SearchSidebarNavigation.vue

反例：

components/

|- SearchSidebar.vue

|- NavigationForSearchSidebar.vue

6. 组件名中的单词顺序

组件名应该以高级别的 (通常是一般化描述的) 单词开头，以描述性的修饰词结尾。

正例：

components/

|- SearchButtonClear.vue

|- SearchButtonRun.vue

|- SearchInputQuery.vue

|- SearchInputExcludeGlob.vue

|- SettingsCheckboxTerms.vue

|- SettingsCheckboxLaunchOnStartup.vue

反例：

components/

|- ClearSearchButton.vue

|- ExcludeFromSearchInput.vue

|- LaunchOnStartupCheckbox.vue

|- RunSearchButton.vue

|- SearchInput.vue

|- TermsCheckbox.vue

7. 模板中的组件名大小写

总是 PascalCase 的

正例：

!-- 在单文件组件和字符串模板中 --

MyComponent/

反例：

!-- 在单文件组件和字符串模板中 --

mycomponent/

!-- 在单文件组件和字符串模板中 --

myComponent/

8. 完整单词的组件名

组件名应该倾向于完整单词而不是缩写。

正例：

components/

|- StudentDashboardSettings.vue

|- UserProfileOptions.vue

反例：

components/

|- SdSettings.vue

|- UProfOpts.vue

9. 多个特性的元素

多个特性的元素应该分多行撰写，每个特性一行。

正例：

img

src="htorg/images/logo.png"

alt="Vue Logo"

MyComponent

foo="a"

bar="b"

baz="c"

/

反例：

img src="h/logo.png" alt="Vue Logo"

MyComponent foo="a" bar="b" baz="c"/

10. 模板中简单的表达式

组件模板应该只包含简单的表达式，复杂的表达式则应该重构为计算属性或方法。

复杂表达式会让你的模板变得不那么声明式。我们应该尽量描述应该出现的是什么，而非如何计算那个值。而且计算属性和方法使得代码可以重用。

前端开发过程中遇到过什么困难？

前端开发过程中遇到的困难还是很多

1、面试中前端开发过程中遇到的困难这个问题主要是相看面试者是不是有独立解决问题的能力及解决问题的方案以及工作中的的一些两点

2、遇到这样的问题可以说出一个自己解决的比较完美的问题，如：vue不适合做cms，因为单页面应用对seo很不友好，解决的方法就是：我们使用nuxt技术，在保证使用vue语法开发的同时，也使用了服务端渲染技术保证了seo效果，这个过程突出了自己的学习nuxt等新技术的能力

3、另外也是有很多实际的开发问题不好解决，的但是那些自己解决不好的问题不适合 在面试的过程中说的

前端开发的难点到底在什么地方

业务逻辑很复杂而且多变

『前端的逻辑复杂度基本不如后端』这个只是但从数据处理的角度来看的，前端对于数据处理的确是模板 + 变量一套一展示就好了，这个是挺简单的。

前端逻辑复杂度主要在于数据 + UI + 交互的实现，就比如一个简单的多 tab 页的功能，可以用 CSS 实现、用 JS 实现，JS 可以通过切换 remove DOM 或者添加 classname 隐藏，虽然效果上都可以实现，remove DOM 无法原有结构的状态，添加 classname 的 CSS 方式很难实现初始化状态。除此之外还可能需要对浏览器进行兼容性处理 + 响应式。然后突然来个业务需求说要加个 iframe 嵌入别人的页面，或者改什么效果，如果之前开发的不合理，基本上要重做了。

相比后端，只输出数据模型给前端，如果业务不需要什么字段了，甚至让前端不读取好了，改都不用改。我们几次大的业务平台重构，前端基本要重新开发一遍（效果、交互完全不同），后端模型和数据库则可以递进式的复用、扩展、升级。这也是导致前端需要堆人大力出奇迹的问题。

垂直领域解决方案很难

切页面是没什么难度的，但是在淘宝一到双十一、双十二大促根据经常多变的运营需求切几百个页面就很难了。这已经不是堆人堆外包可以解决的了，所以我们有 TMS 等各种运营系统，前端切模块，运营自己设置图片、文案、组装成运营页面，想改自己在后台改不用麻烦前端。这一套系统是个比较庞大的工程，从模块规范、模块开发工具链、模块发布和版本管理、在线管理、在线可视化搭建、数据填写和数据源导入、页面生成和 CDN 同步等等，都需要前端架构师设计然后开发。设计这个系统是很难的。

再比如富文本内容发布业务需求，光是一个富文本编辑器就很复杂，要实现各种功能和兼容性，更复杂的是要适应业务发展。当时刚开始交接淘宝内容业务的时候，需要重新开发编辑器等，跟后端大神们进行讨论推测未来业务可能会有大量表单而且需要完全的数据驱动，所以我们前端设计开发了 现在有个项目表单很多，用什么技术框架合适？ - 知乎 技术产品然后后端有对应的 SDK 进行解析和数据存储、表单生成服务，前端只需要开发组件，然后后端按照业务需求进行配置即可产出内容发布表单。

此外，富文本我们选用了 JSON base 的存储，对比 HTML base 的编辑器，因为淘宝内容详情页充满了各种商品、优惠券、店铺等信息，而且这些信息是需要被理解、识别而且在详情页输出前实时补全最新价格、优惠券可用状态、店铺名等信息的。用传统输出 HTML 的编辑器输出，让后端解析的话复杂度太高了，每一种素材你都需要设计、约束特定的 HTML 标记让后端进行解析。所以我们基于 跳转中... 封装了一套 JSON base 的富文本编辑器，设计了完全数据驱动的插件机制，可以通过配置任意控制要提供的功能等。

           虽然知乎的编辑器也是基于 draft-js 开发的，但遇到的业务挑战完全不同。它不需要功能动态变化，因为所有人都一样。然后不知道是后端的数据处理逻辑的问题，它在提交和回填的时候是通过 HTML 作为媒介进行传播，将 draft-js 的 JSON 数据协议转成 HTML 提交给后端存储。所以不同业务场景、特点，需要完全不同的前端解决方案，在开发这些垂直解决方案的时候，业务分析、技术选型、架构设计、开发落地是非常难的。

前端vue项目中遇到的难点的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于在vue项目中遇到的最大的困难、前端vue项目中遇到的难点的信息别忘了在本站进行查找喔。