未分类Category

Tailwind介绍 前言 众所周知，CSS是一个相对简单且语法宽松的语言，虽然对开发者友好，但因为它过于“随意”且耦合性强（如height和line-height都会对元素的高度造成影响），如果开发时不做限制，对后续维护的人员来说将会造成“毁灭性打击”。 故为了样式代码的可读性，也为了减少维护人员受到的心理创伤，我们需要对CSS的编写做出限制 BEM命名规范 😀 一般来说，我们编写CSS时类名会遵循BEM命名规范，这种规范的特点是语义化、结构化、遵循开闭原则。参考知乎——CSS之BEM命名规范 “开闭原则”指对修改封闭、对扩展开放，是面向对象思想的重要基本原则 BEM规范存在的问题 😐 语义化的CSS类看似与HTML无关，但在嵌套的CSS选择器（如使用less时）中却反映出了具体的HTML结构。除此以外，CSS里还有很多会被父元素或子元素影响的属性，故将CSS与HTML解耦实际上是很困难甚至无法达成的 在处理两个外表相似的内容时（如下图的作者简介和文章预览），即使样式决策有99%是一致的，我们也很可能需要编写两个语义不同的类来赋予它们样式(如.author-bio和.article-preview)，并且这两个类是几乎不可复用的 实际上，可以通过一些CSS预处理器的如 @extend 等功能实现复用，但会对后续维护造成很大的困扰 即便将类拆分到每个组件，使其不基于内容（如.card .button）虽然可以在一定程度上复用这些类，但当组件功能越具体，复用就会越困难（如.dialog-header__button） 给CSS类命名是令人费神的 原子类 原子类，指具有“原子性”的CSS类 在化学反应中“原子”是最小的单位，故“原子性”指具有不可拆解、不可更改的性质 示例： .flex { display: flex; } 上面的.flex就是一个原子类，它的特点就是一个类名对应一个CSS规则，并且类名应该是和规则有关系的 原子类的思想可以说与我们常用的BEM规范“背道而驰”，BEM强调的是语义化与将CSS从HTML的关注点分离（实际上很可能没有分离），而原子类几乎摒弃了语义化，通过使用提供的大量工具类使页面符合最终的设计决策 Tailwind基本概念 Tailwind就是一个采用了CSS原子类和“All in JS”思想的框架 “All in JS”指“HTML in JS”和“CSS in JS”，其中“HTML in JS”就是Vue、React等框架在做的事 框架特点 Tailwind 提供了一组可重用的 CSS 类，可用于几乎任何类型的 UI 组件和布局。 Tailwind… Continue Reading Tailwind 入门

一、JDK版本问题 由于之前开MC服务器时安装过Java1.20.x版本，后面在装Android SDK时就没注意安装相应的JDK版本，导致用yarn android启动时报错 错误信息： BUG! exception in phase ‘semantic analysis’ in source unit ‘BuildScript’ Unsupported class file major version 64 查了一会发现是JAVA版本过高导致的，降级成1.17.8后重新配置环境变量即可 二、Andriod SDK环境变量配置问题 一个低级错误= =，官方文档中已经写了要配置这些变量： %ANDROID_HOME%\platform-tools %ANDROID_HOME%\emulator %ANDROID_HOME%\tools %ANDROID_HOME%\tools\bin 自己配置时漏了一个%ANDROID_HOME%\emulator，导致启动时无法找到安卓模拟器，又报错，加上后解决 三、Andriod Studio下载速度过慢 虽然一开始就知道Android开发需要合理上网，虽然下SDK速度挺快的，但下依赖的速度还是很慢，导致等了两个小时快下载完依赖的时候网络超时，又得重新下，因为不愿意再等两个小时，遂查找解决方法，发现gradle仓库源可以在项目里配置 将/android/build.gradle中的 repositories { google() mavenCentral() } 加上两行替换为阿里云源 repositories { maven{url 'https://maven.aliyun.com/repository/google'} maven{url 'https://maven.aliyun.com/repository/public'} google() mavenCentral() }… Continue Reading 记录搭建React Native环境时遇到的几个坑

问题来源 由于查询条件改变频率高，或者后端数据处理逻辑复杂，导致接口返回的顺序跟实际请求的顺序不一致。 如：同一接口，先用复杂度高的查询条件发A请求，然后在A还没返回时发简单的B请求，且B返回数据后A才返回，此时若是用 *.then(res => …) 来处理的话，会出现最终使用的是A的返回数据的情况。 解决思路 由于涉及的场景不算复杂，故不打算使用类，个人选择了工厂函数的模式，考虑用两个变量分别保存当前已发送的请求数量，及当前请求的索引，分别记为A，B A初始为0，每次请求时加一，并将A赋值给该请求的索引B，请求返回时对比A和B，则： 若 A > B，说明不是我们期望的请求，在返回的数据中作标记，并在请求返回的回调函数中进一步处理 若 A = B，说明是我们应该处理的请求，将A置为0并返回原数据即可 正确的实现不应该出现 A < B 的情况 代码 /** 例如: * const fetchOptions = limitRequest() * fetchOptions({ url: 'http://www.baidu.com' }).then(res => { console.log(res) }) **/ const limitRequest = function() { const num = new… Continue Reading 解决方案——多次发送同一请求，仅响应最后一次