Astro-颠覆传统-不同凡响的前端框架 (astronergy正泰太阳能)
前端技术突飞猛进，最后的静态网站逐渐被由服务端生成的网站所取代，起初又逐渐向客户端渲染的运行转变。不过客户端渲染也存在一些疑问，如加载期间变长和搜查引擎优化难度等。Astro这个新的前端框架联合了服务端渲染和客户端渲染的优势，可以更好地处置这些疑问。
本文就来引见一下这两年爆火的前端框架Astro，它在两年的期间新增了30k+star:
这个前端框架，有点不一样。
Astro基本概念
Astro是一个开源的Script框架，用于在盛行的UI框架（如React、Preact、Vue或Svelte）之上生成Web运行。Astro的页面由多个独立的组件组成。为了提高加载速度，Astro会在服务端对页面启动预渲染，并剥离一切JavaScript，除非将某个组件标志为交互式，此时Astro将发送必要的最小量JavaScript以成功交互性能。
经过这种战略，Astro页面加载速度快，由于在初次渲染时不须要执行任何JavaScript。在注水的环节中，Astro会将JavaScript注入到组件中，使它们变成灵活的。
Astro历史开展
Astro最后的设计并非与React或Vue等竞争，而是为了支持互操作性。简而言之，就是可以在Astro中经常使用青睐的工具！它提供了对React、Vue、Svelte和Tlwind等前端工具的一流支持。
但是，Astro真正的亮点是名为岛屿的前端架构范式转变。Astro的岛屿架构能够提高运行的速度，它将UI拆分为更小的、隔离的组件，并在静态页面中局部启动交互式组件，这是一个大胆的翻新。
如今，Astro曾经开展成一个现代Web框架，可用于构建极速的多页面运行、灵活主机端点和器重内容性能的网站。虽然保管了便捷性和外围性能，如主机端点、内容汇合、视图过渡以及杰出的开发者体验，但Astro正始终演进，成为一特性能弱小的现代Web运行程序框架。
Astro上班原理
Astro的外围是其岛屿架构。那么Astro中的岛屿是如何运作的呢？这就不得不说它的岛屿架构和局部水合了。
咱们知道，客户端和服务端是向用户提供运行的两个关键介入者：
上方来看一个在客户端上从新水合的服务端渲染的运行的例子。
服务端渲染简化的环节如下：
这是形容局部水协作用的简双方法。咱们没有对整个运前启动水合处置，而是专一于运行的较小交互局部并独立地对这些局部启动水合处置：
Astro岛屿就是嵌入静态页面中的交互式UI组件。一个页面上可以存在多个岛。每个岛都是经过独立的局部水合形式启动渲染。也就是说，每个岛都是独立水合的。
那这么做有什么好处呢？
经过应用岛屿，Astro运行可以具有杰出的初始加载期间，而不会遭到JavaScript的限度。大局部站点坚持静态形态，只要在初始页面加载之后须要时才会对交互局部或岛启动水合。
Astro关键性能
上方引见了Astro的岛屿架构和局部水合，上方来看看Astro的外围性能，以更有效的经常使用它。
组件
Astro运行的最小单位是组件。组件导致了每个Astro运行的基础：
Astro组件文件都以.astro开头。
与大少数其他前端框架相似，组件内的形象水平由开发者自己选择。例如，组件可以是UI的一小局部可重用的组件，例如页眉或页脚，或许组件可以足够大以导致整个页面或规划。
来看看上方的HelloWorldAstro组件：
//HelloWorld.astro---constname="前端充电宝"---<h1>Helloworld,{name}</h1>可以看到，Astro蕴含两个局部：组件脚本和组件模板
组件脚本是蕴含在虚线之间的局部，与Markdown前面的内容块相反。在脚本局部中，自动状况下，可以编写任何有效的JavaScript和TypeScript！在上方的例子中，定义了一个变量：
---constname="前端充电宝"---组件模板就是定义组件HTML的中央。假设组件须要向阅读器渲染一些UI元素或HTML，可以在此处定义它。在上方的例子中，定义了以下内容：
<h1>Helloworld,{name}</h1>Astro组件模板选择了组件的HTML输入并支持纯HTML！不过，Astro组件模板语法是HTML的超集。它参与了弱小的插值性能，因此可以充沛应用JavaScript和TypeScript来编写组件模板。
除了便捷的字符串插值之外，组件模板语法还支持很多性能，例如参与和标签、应用灵活属性、条件渲染、灵活HTML等。以下是其中一些性能的展示：
---constisActive=false---<h1>前端充电宝</h1>{/**条件渲染**/}{isActive&&<p>HelloWorldfrom前端充电宝</p>}{/**样式：自动状况上样式是有作用域的**/}<style>h1{color:red,}{/**参与脚本**/}<script>constheader=document.querySelector("h1")header.textContent="UpdatedLogRocketHeader"</script>页面和路由
Astro运行的入口点是页面，它应用基于文件的路由形式来治理页面。
假定正在构建一个具有两个不同路由的Web运行：index.html和about.html，那该如何示意呢？
Astro名目的src/pages/子目录中的每个文件对应一个页面。在这个例子中，须要两个页面：src/pages/index.astro和src/pages/about.astro：
在构建运行时，可以经过像npmbuild这样的便捷命令来启动构建，index.astro和about.astro将被构建成运行中相应的index.html和about.html文件。
Astro是一个多页面Web框架。也就是说，自动状况下，每个路由都对应一个独自的HTML文档。
可以依照以下步骤来尝试经常使用Astro：
在Astro中，不只可以经常使用.astro组件作为页面，还可以经常使用以下形式构建页面：
灵活路由
上方咱们探讨了页面和HTML输入之间的一对一映射，不过，在Astro中也可以经过一个页面处置多个路由。
Astro页面可以在文件名中指定灵活路由参数，这将生成多个婚配的页面。例如，构建一个博客运行，其中每篇博客都有自己的路由，可以经过以下形式示意该页面：
src/pages/blogs/[blog].astro留意，组件文件名中的方括号：[blog].astro。在静态形式下，一切路由都必需在构建时确定。因此，灵活路由必需导出getStaticPaths()方法，该方法前往具有params属性的对象数组。这通知Astro在构建时生成哪些页面。
例如：
//src/pages/blogs/[blog.astro]---exportfunctiongetStaticPaths(){return[{params:{blog:"how-to-learn-astro"}},{params:{blog:"how-to-learn-ai"}},{params:{blog:"how-to-learn-astro-ai"}},]}//可以从Astro全局对象中解构参数const{blog}=Astro.params---<h1>HelloBlog,{blog}</h1>当构建此运行时，src/pages/blogs/[blog.astro]将生成三个博客页面：
Astro还支持服务端渲染，在这种状况下，路由是在运转时而不是构建时生成的。这象征着不须要指定getStaticPaths()方法，并且页面可以大大简化，如下所示：
//src/pages/blogs/[blog.astro]---//可以从Astro全局对象中解构参数const{blog}=Astro.params---<h1>HelloBlog,{blog}</h1>在通常中，经常使用SSR，这里的博客参数很或许是博客的惟一标识符，例如ID。当用户尝试检查/blogs/id时，可以经过Astro.params失掉id并在服务端失掉所需的博客内容。
规划
除了反常的组件和不凡的组件页面，上方来了解另一种类型的组件：规划。
大少数Web运行都蕴含一些可重用的结构，这些结构为页面提供了却构，例如页眉、页脚和正面导航元素。这些可以被形象为可重用的Astro组件，称为规划。
可以经过在src/layouts目录中参与Astro组件来创立规划组件：
在规划组件中，可以形象公共组件并在恣意运行页面中重用它们。
来看上方的规划组件：
//src/layouts/Main.astro---const{title}=Astro.props;---<!doctypehtml><html><head><meta/><meta/><meta/><link/><metacontent={Astro.generator}/><title>{title}</title></head><body>{/**留意，上方经常使用了<slot/>标签**/}<slot/></body></html>可以在任何页面中经常使用此组件：
---importMainfrom'../layouts/Main.astro';---{/**像渲染HTML元素一样渲染Main组件：<Main></Main>**/}<Main><main><h1>Helloworld,again</h1><main></Main>留意这里是如何经常使用规划组件的。在页面组件的HTML局部中，渲染了规划组件，并将页面的元素作为子元素传递给了<Main>组件。
可以经过在<Main>组件中参与一个<slot/>来渲染这个内容。简而言之，每个传递给<Main>规划组件的子元素都将被渲染到<Main>中的<slot/>中：
还可以经过提供props来提高Astro组件的可重用性。例如：
上方的例子就是在规划组件渲染时将不同的题目传递给它：
//src/layouts/Main.astro---const{title}=Astro.props;---<h1>{title}</h1>主题和模板
Astro在过去几年中的增长很大水平上归功于它的易于驳回和开发。Astro经过提供多样化的模板，为工开发者极速启动名目并编写更少的代码提供了极大的便利。
两边件
两边件在协助Astro转变为成熟的Web框架的环节中施展了关键作用。
大少数全栈Web框架都有两边件成功，例如NestJS。两边件位于客户端恳求和主机运行逻辑的其他局部之间，起到中心化逻辑的作用，例如身份验证、日志记载、特性标志等。
Astro也提供了两边件，上方是Astro中基本两边件的结构：
//src/middleware.js|tsimport{defineMiddleware}from"astro/middleware";constmiddleware=defineMiddleware((context,next)=>{//在这里对恳求启动一些操作returnnext()//不启动任何操作，原样转发恳求});exportconstonRequest=middleware;为了类型安保，可以从Astro包中导入MiddlewareResponseHandler类型以及defineMiddleware适用程序。而后，经过defineMiddleware适用程序定义两边件变量：
constmiddleware=definedMiddleware(...)最后，导出一个指向middleware的onRequest函数。
exportconstonRequest=defineMiddleware(...)Markdown和ContentCollectionsAPI
假定你正在构建一个大型的内容驱动运行，这样的名目估量会经常使用少量的Markdown、MDX、JSON或YAML文件。
组织名目内容的最佳通常是将内容数据保管在数据库中，可以在数据库中验证文档结构并确保所需的内容合乎咱们想要的数据模型。
经常使用此处置打算时，可以将它们示意为存储在具有预约义架构的数据库中的数据汇合：
在大少数静态站点生成器中，验证本地形式是很艰巨的。Astro经过其ContentCollectionsAPI（内容汇合）提供了强类型安保性，扭转了这种状况。
内容汇合是Astro名目的src/content文件夹中的任何顶级目录：
汇合中的单个文档被称为汇合项：
以这种形式组织大型内容驱动的网站的好处在于，可以应用Astro的类型安保性来查问和处置内容汇合。例如，可认为内容汇合引入一个形式，如下所示：
如今，src/content/blog汇合中的每一项都必需遵守此结构。
上方来验证一下每个Markdown的题目。例如，假设有以下内容，就会收到TypeScript失误，由于不满足咱们定义的结构：
---title="HelloWorld"---#前端充电宝helloworld！无论Astro名目有多大，内容汇合都是组织内容文档、验证文档结构以及在查问或操作内容汇合时享用开箱即用的TypeScript支持的最佳形式。
视图转换API
明晰且炫酷的页面过渡不只可以增强用户体验，还可以建设流动方向并突出展现了不同页面之间元素的相关。这就是ViewTransitionsAPI施展作用的中央。
Astro的ViewTransitions是一组新的API，旨在经常使用ViewTransitions阅读器API原生地操纵页面过渡。Astro是第一个将ViewTransitions引入干流的关键Web框架。
要开局在Astro名目中经常使用ViewTransitionsAPI，只要导入ViewTransitions。而后，在宿愿提供页面转换的源页面和指标页面的头部渲染组件：
//some-page.astro---import{ViewTransitions}from"astro:transitions";---<head><ViewTransitions/></head>//...ViewTransitions担任将客户端脚本参与到原始页面，以阻拦对其他页面的点击。
Astro经常使用场景
说完了Astro的外围性能，上方来看看Astro的一些经常出现用例，假设须要开发内容驱动的网站，低提前是很关键的，Astro就是一个很好的选用。
博客、作品集
假设你的团体博客或作品集是一个静态网站，那么经常使用Astro是一个理智的选用。除了提高网站性能外，Astro的组件化架构还准许你在适当的位置轻松地参与灵活性能。
还可以集成Markdown以取得更好的创作体验，并应用Astro的服务端渲染来坚持友好。简而言之，假设要在2024年构建静态网站，Astro是你的最佳选用。
文档站点
文档站点通常具有少量内容，Astro在这方面体现杰出。Astro还有一个名为Starlight的公用文档框架，可以极速启动和运转。假设须要一个洁净、直观的文档网站，可以极速加载以提供所需的信息，那么Astro是一个不错的选用。
Web运行
Astro不只限于静态网站。通常上，它还可认为灵活Web运行提供能源。
但是，在这方面须要小心。虽然可以轻松地经常使用React、Vue、Svelte等选项开发完整的Web运行，但只要在确实无心义的状况下才招思考经常使用Astro。
关于能否在全栈运行中经常使用Astro，应该思考：能否应用islands来优化运行的性能？换句话说，能否想要构建一个大局部是静态的、具有按需加载的islands的多页面运行？
假设答案是必需的，可以尝试经常使用Astro。
AstrovsNext.js
Astro和Next.js都是现代JavaScript框架，旨在创立高性能的运行。但是，Astro最后是作为静态站点生成器开发的，而Next最后是作为构建具有形态治感性能的丰盛运行的框架：
虽然Astro依然是静态网站的绝佳选用，但它也致力增加差距，以创立更多有形态的运行。但是，即使可以在Astro中渲染完整的React客户端运行，这并不必定象征着你应该这样做。
假设你的网站大局部是静态的并且性能是优先思考的，可以思考经常使用Astro。假设正在构建一特性能丰盛、有形态的运行，Next或许是更好的选用。
值得留意的是，静态和有形态之间的区别或许并不总是很分明。齐全可以领有一个混合了两者的运行。最终，框架的选用取决于详细用例和业务要求。
前端有什么框架呀？
一、 Web前端框架之Angular 2+
Angular 2+优点解析：
Angular 2+ 的最大优势在于它的流行程度。也有人认为它和 Google 密切相关的名字，会影响团队使用它。Angular 1 的迅速流行是因为那些来自其他交互式应用程序开发环境的人会发现对于开发单页面 Web 应用程序具有相似的模型-视图模式。通过对 Angular 1 进行现代化演变和重新构建框架的某些部分，Angular 2+ 已经真正的爆发了，大量的正式的和非正式培训机构数量都让人印象深刻，开发者有很强的市场竞争力。对于用户来说它有一套用于构建用户界面的丰富组件，这也是本系列中少有的几个框架能够做到这点。
缺点解析：
我们觉得 Angular 框架着重于在单个页面应用程序中创建用户界面并没有处理构建完整的 Web 应用这个更大的关注点，如果不及早确定下来，这将会导致整个项目难以维护，在实际项目中，运行时提供不属于核心框架的技术往往让人觉得不可思议，这大大降低了 TypeScript 对最终开发者的价值。
发展方向：
Angular 5 刚刚发布，这看来是 Angular 已经成功的印证了快速发布版本的承诺，在 Google 的持续支持下，Angular 会越来越成熟。
像许多的大型组织一样，Google 具有多重(分裂)的人格，从外表上看，Angular 团队和那些专注于浏览器标准的团队之间显得很和谐。但我们的观点是，和谐只是一层薄薄的窗户纸。Angular 团队对于 Web 组件和渐进式 Web 应用没有一个真正解决方案。我们认为，业界普遍认可的标准将会在 Angular 框架中会逐步实现，这将会影响到如何更好的构建 Angular 应用将成为一个中/长期的风险。
使用环境：
如果你需要在一个大型的框架内获取技术资源，框架内的技术通常很容易移植;或者你需要在框架中训练开发人员，并且还要有一定的信心，他们会在短期内获得一定的开发能力，这样的话你可以考虑 Angular 2+ 。需要注意的是 Angular1()与 Angular2+ 是截然不同的，其中的应用、技术和经验不能直接移植到 Angular2+ 的开发中去。
如果你的 Web 应用能够很好的转化为标准的模型-视图模式，那么你也可以忽略其他直接考虑使用 Angular2+ 。
如果你对 Google Material UX 设计模式满意，那么 Material Angular 是遵循该模式的一种快速、简单且可靠的方式。
二、Web前端框架之React + Redux
React + Redux优势解析：
React 和 Redux 的最大优势在于它们相对简单和专注。做一件事情并把它做好是非常困难的，但这两个库都很有效地完成了它们的目标。虽然对于某些状态容器方法可能是外部的，但大多数开发人员还是可以轻松掌握概念，并了解单向数据体系结构的好处，简化大量的用户界面应用程序。
缺点解析：
React 和 Redux 最大的弱点不是它们是什么，而是它们不是什么。要构建一个功能丰富的 Web 应用程序，你需要许多功能，一旦脱离 React 和 Redux 和其他一些库的核心，你将发现一个非常分散的社区，拥有无数的解决方案和模式，不容易整合在一起。
因此，虽然 React 和 Redux 都是非常专注的库，但缺乏经验的团队还是会很容易地生成不可维护的解决方案，而不是意识到他们所做的选择会导致性能不佳或错误。即使有经验的开发人员也可能意识到，一个松散的架构或惯例可能会在未来困扰他们。
假省钱是一种对自己的欺骗，组织范围内采用 React 和 Redux 将轻松降低无效率问题。没有其他库和模式的广泛约定和标准化，标准化 React + Redux 比较于我们正在采用的 JavaScript 来编写我们的应用程序效率要高。
发展方向：
Facebook 和 React 最近从繁琐的附加专利纠纷中抽离，他们认识到，就像其他项目一样，更广泛的社区能够提高自己的声音。我觉得这有助于 Facebook 意识到他们还不能更好地了解我们，相信我们来引导项目。希望这将继续贯穿项目的特点和技术方向。
很难预测 React 和 Redux 的未来。但是，将库集中在一起，确实会显着提高适应性，大多数React + Redux 模式都会促进一个分离的体系结构，从而可以轻松地进行重构和迭代。两年前，大家喜欢的还是React + Flux，但整个社区很快就拥抱了Redux。思维或模式的其他重大转变可能很容易被采纳。这种关键能力可能会持续到未来。
使用环境：
如果你很少需要手把手指导，并且正在寻找更好的库而不是全面的框架，那么 React + Redux 可能是正确的。在这一过程中，你不仅需要对你的团队和组织的能力保持诚实，还要在你的初始开发过程中，以及在整个应用程序的长期维护过程中保持诚实。
三、Web前端框架之
优势介绍：
渐进式构建能力是最大的优势，vue 有一个简洁而且合理的架构，使得它易于理解和构建。
vue 有一个强大的充满激情人群的社区，这为增加了巨大的价值，使得为一个空白项目创建一个综合的解决方案变得十分容易。
缺点介绍：
在模型-视图应用程序和状态容器类型的应用程序之间的互相转换可能会令人感到困惑，即使没有完美包含一个模式到另一个模式的完美转换，但让人感觉希望能维持两个模式的相关性。对于那些期待完美解决方案，并可能导致难以维护不一致的应用程序的人来说，这至少是令人困惑的。
一个更大的挑战是依赖于一个单独的人，很明显，其他的项目基本是由一个组织提供支持，但这让人感觉更加有意义，虽然它有一个强大文件的社区和许多有创新的新增项目，但是 vue 核心的开发基本落在一个人身上。
我们很高兴看到 vue 更加容易接受新兴的标准方法，但是它的类似于 Web 组件的模式，而不是真正的 Web 组件，这可能是 vue 所得不偿失的地方。
发展前景：
虽然有相当广泛的应用，但也很难预测在中期发展中这个势头能持续多久，它不是由一个商业组织直接支持并维护，因此，这很大程度上依赖于维护者的生存能力和继续维护下去的愿望来决定。
它也表现出了一定程度的语言适应能力，并且随着某些模式的落伍和失宠而继续保持自身语言的现代化和时代性，目前没有迹象表明架构将来无法适应进一步发展。
使用场景：
如果你有一个传统的Web应用程序，并需要一个强壮稳健的应用程序层，那么 可能是一个很好的选择，它有清晰的模式，即使没有经验的团队也能正确或者错误的使用它。尽管vue UX框架没有开箱即用的功能，但在上也能大量持续性构建应用，这将有利于你的项目。
一个小程序的后台是web端
小程序第一个web项目-微信小程序后端开发第一个web项目-微信小程序后端开发前言需求分析团队分工总体设计开发工具及编码实现小程序前端后端数据库接口代码管理系统前端1.0管理系统前端2.0测试后端本地测试前后端联合测试部署总结第一个web项目-微信小程序后端开发前言去年暑假一个偶然的机会我和几位同学加入了学院一位老师主持的教改项目，需求是开发一个基于SPOC与翻转课堂的计算机组成原理课程的学习app（类似慕课、知到），后来经过讨论决定降低难度，先做一个微信小程序，附带一个后台管理系统，于是我的第一个web项目就开始了~需求分析这里简单介绍下SPOC和翻转课堂的意思翻转课堂“翻转课堂”（Flipping Classroom）是一种颠覆传统教学由“课堂授课听讲 + 课后作业练习”转变为“课前自主学习 + 课堂协作探究”的新型教学模式。 SPOCSPOC（Small Private Online Course）一般被译为小规模限制性在线课程或者小规模私有型网络课程，音译为“私播课”。 这次项目的需求是开发一个学习类型的小程序，用户分为学生和教师，其中学生可以观看视频、课件、动画，完成作业、考试以及发布评论、点赞、回复，而教师可以上传教学视频、课件、动画和发布作业、考试、通知，以及查看学生的学习情况，也可以查看评论回复，及时解答学生的疑惑。 团队分工团队一共有四个人，总体工作分为产品设计、前端开发、后端开发三部分，然后每部分由两人负责。 其中我是负责后端开发的，同时兼任项目负责人（其实也没有听上去那么高大上，只是需要承担更多决策、协调、沟通的角色）。 总体设计这里分为小程序和管理系统首先是小程序，放几张使用墨刀制作的原型图，这里多说两句，市面上的小程序基本都是微信授权直接登录，最多绑定手机号，我们这个由于要统计学生的学习情况才设置了注册和登录功能至于管理系统，由于是10月份才开始做的，而且是我和另一位做后端的同学负责的，时间比较紧，我们作为前端小白没有十分系统的方法去做开发，只是大概确定了需要做哪些模块，每个模块对哪些表的增删改查，这里原型图就不放了（较简陋）开发工具及编码实现小程序前端据我了解，做前端的同学先去微信公众平台注册账号，然后做一些开发设置，具体步骤自行网络。 前端用的是微信开发者工具，有不会的基本上在微信开放文档都可以找到，包括许多实用的API。 后端这里分为数据库、接口代码两部分数据库用的是mysql数据库，之前是跟着学堂在线的一个小程序入门教程做的，它推荐的本地开发环境是phpstudy，里面集成了php、mysql、apache、FTP、Nginx以及数据库管理工具phpMyAdmin，关于phpMyAdmin使用请看原本的数据库设计得不好，存在较多冗余数据，后来学习了数据库系统这门课，我进行了大改，先确定有哪些实体以及实体之间的联系，然后画er图，最后再建模，通过外码约束大量减少了冗余，也减少了表的数量。 接口代码教程使用的是php语言，框架是thinkphp5，开发手册看，我当时是去b站找视频学了下php基础语法，然后就去学原生php以及框架如何操作数据库。 然后根据业务逻辑开始编码，其实每个接口（或者叫类里面的一个函数）结构都差不多，主要是三部分：接收前端传来的数据、增/删/改/查、返回结果给前端。 顺便说下代码编辑用的是sublime text3，教程看，这个不是ide，没有那么多的功能比如调试、运行，单纯是只有编辑、加注释、格式化等等，这里吐槽下自带的格式化代码功能（先选择代码，再Edit -> Line -> Reindent），有点辣鸡。 而且如果有语法错误不会像eclipse那样自动检测出来，之前被坑了几次，肉眼找不到的话只能用postman去测试了。 管理系统前端1.0一开始我们是不知道还要做个管理系统的，以为所有功能都放在小程序，后来老师跟我们讨论聊到这个问题，我们才知道原来还有这回事，其实就是管理系统应该具有一切功能，即对数据库所有表的增删改查，而小程序只需要有些轻量的功能即可，至于上传大容量文件、查看学习情况这些不够轻量的功能全部放在管理系统。 好吧，凡事总有第一次，我们就开始学习基本的前端三件套html,css,javascript。 开始做的时候我们希望先实现功能，界面难看点没有太多关系，于是学了部分三件套的基础后又学了ajax技术（因为要与后端通信），这里最开始用的是创建XMLHttpRequest 对象，用open()方法设置请求类型和url，用send()方法发送数据到后端，直到遇到了jquery，后面的请求统一都用$()了。 接下来又遇到了一个难点，因为基本都用表格来展示数据，那获取数据后如何动态地加入表格呢？查找资料后用每一条数据拼接成由tr标签包含的字符串，然后用jquery获取表格标签后调用append()方法加入表格中。 除此之外，我们想在每行末尾设置按钮进行事件处理，于是我们append数据的同时也把button标签放入刚才的字符串中，然后给每个button设置id属性，比如用于修改数据的就叫fixi，最后这个i是代表表格第几行，然后添加事件监听，点击button时获取id，然后查看最后一位是多少从而确定是第几行。 这些做法实现起来是挺繁琐的，而且感觉在重复造轮子，我们也做得有点郁闷，因为每个页面基本都要这样做，但是当时没有那么多的时间精力去学习框架，只是想先实现功能（u1s1，上学期的课多到我快吐了）。 放两张界面图管理系统前端2.0之前放假，总算有较多空余时间了，我们决定要改下界面，但毕竟自身水平不高，因此需要用一点第三方的东西了。 在跟小程序前端测试了部分功能后，有一天后端同学找到了一个开源的框架然后我们一起看了下说明文档，最后决定：就用它了。 有请layui登场，经典模块化前端框架、低门槛开箱即用。 真正使用之前可以先看看文档，个人感觉上手还是挺快的。 layui提供了许多实用的组件包括弹出层、表格、表单、文件上传、流加载等等。 就拿表格来说，之前我们用append动态添加数据，现在直接()，设置好参数就行了；之前我们给button设置id进行事件处理，现在绑定工具条，直接()就行了；而且之前我们没实现的分页，现在设置分页参数就行了，然后查询数据库时分页读取。 另外，layui提供了一个页面布局的模板，包括logo、用户名、退出按钮、导航栏以及一些css动画。 我们要做的就是按照它的模板来，页面元素的样式也参考它提供的。 有了layui的助攻，我们可以将更多注意力放在业务逻辑上，更多关注用户体验。 测试后端本地测试工具：postman使用：打开一个新窗口，选择请求类型，输入url，设置参数，点击send这种测试我认为是模拟前端发送数据然后运行后端代码，看结果是否正确，属于白盒测试，但是我们不是专业测试人员，目前这样测试不是做得很规范，只能尽可能想到不同的测试用例。 前后端联合测试由于放假回家了没办法面对面，只能借助腾讯会议线上测了。 在部署工作完成之后，一般是我们写好接口代码，然后把url和需要的参数告诉前端同学（这里注意下，微信小程序的请求api只允许https开头的url，而且前端必须在微信公众平台配置好合法域名，不然会报错），前端把这些东西填入那个的api然后运行，他们会查看返回的数据是否正确，我们会查看数据库的情况，如果没问题会测试多几个数据，都可以的话就到下一个功能，这种方式应该是属于软工讲到的V模型的单元测试。 部署用的是新浪云，实名认证、学生认证后会送一些云豆（新浪云的计费单位，1RMB=100云豆）跟着之前说的教程把整个thinkphp项目部署到新浪云，具体步骤看代码在代码管理那里可上传压缩包，或者在线编辑（跟记事本差不多），改动大的最好在本地写好再贴上去数据库开启共享型mysql服务，目前用了phpmyadmin4.9版本，然后建表或导入sql文件缓存开启memcached服务，设置容量16MB（省点钱），其实这个服务我不是很清楚干什么的，但如果不打开访问接口时会报致命错误？文件存储我们需要保存许多类型的文件包括视频、课件、动画、作业、考试、头像，因此需要存放在服务端。 这里开启storage服务，使用方法看，普通用户配额5个bucket，每个容量10G，然后直接当作本地磁盘那样用就行了，控制台或写代码都可上传文件，上传后获得url，然后就可以通过网络访问，关于新浪云环境下php如何操作看官方文档。 域名应用信息可查看二级域名，独立域名需要购买且备案日志日志中心可查看每次请求的接口、时间、请求方设备等信息其它控制台还可以实时查看流量统计、资源使用情况，以及消费情况总结这个项目我也算前后端都做了一遍，感觉前端不太适合自己，可能是对页面元素样式、用户体验不够敏感，不过必须承认前端是挺有意思的。 至于后端是更加注重逻辑，目前我对后端的了解只停留在数据库、网络、部署层面，其实如果用户数量非常多还要考虑高并发的问题，也就要使用多线程、负载均衡、消息队列等技术了，所以还有很多技术需要学习
免责声明：本文转载或采集自网络，版权归原作者所有。本网站刊发此文旨在传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题，请联系本网，我们将在第一时间删除。同时，本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证，请读者仅作参考，并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失，本网站不承担任何责任。
