Web 开发问题汇总(四)

1.如何实现如下布局:两个元素A和B,其中A的宽度为包裹其内容,B则占用剩余的宽度?

A:A 元素利用 float 的包裹性,B 元素则利用 BFC。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<div class="container">
    <div class="right"></div>
    <div class="left"></div>
</div>

.container {
    width:600px;
    height:200px;
    border:1px solid;
}
.left {
    width:auto;
    height:200px;
    background:red;
    overflow:hidden;
}
.right {
    height:200px;
    width:200px;
    background:blue;
    float:left;
}

Reference:Expand a div to fill the remaining width

2.Meaning of ~ in import of scss files

A:

From documentation on a sass-loader#imports project,

webpack provides an advanced mechanism to resolve files. The sass-loader uses node-sass' custom importer feature to pass all queries to the webpack resolving engine. Thus you can import your Sass modules from node_modules. Just prepend them with a ~ to tell webpack that this is not a relative import

So if you have a file named foo.css and a module foo then you would use ~ if you want to include the module.

Reference:Meaning of ~ in import of scss files

继续阅读

浅析移动端跨平台开发

最近几年随着移动端开发日益成熟以及 Web 技术的快速发展,跨平台开发技术如雨后春笋一般冒出来,这是所有从业者不能忽视的现象。这种现象导致很多公司主动或被动去研究相关的技术。我也不例外,对它的研究应该是夹杂着被动和主动。作为原生开发者,本来对日常的开发工作驾轻就熟,恐怕内心本身不会有太多意愿去迁移到新的技术,至少我一开始是这种心态;另一方面,跨平台开发在行业内日益受到关注,倒逼开发者去了解它、研究它。对于变化,我们可能本能的抗拒,但内心理性的声音告诉我们:变化是永恒的不变,我们应该拥抱变化。

在经过一段时间的学习和研究,自己觉得对它的认识更加清晰和深刻,于是决定将它们记下来,以便日后记忆模糊了帮助回忆,也可以验证对于它发展的看法。我这里主要谈谈自己对它的看法,技术选择,以及这种技术的基本使用流程。

跨平台开发不是什么新概念,我觉得这是一种很自然的想法。因为我们总是想减轻自己的工作负担,公司则会想减少成本,提高效率,于是就会想能不能一套代码跑到多个平台,两套代码合并成一套,应该可以删除掉不少重复代码,开发和维护的代码量就少了,可能也不需要那么多开发人员了,应该来说还是很有吸引力的。

不过我觉得问题不像看起来那么简单。上面提到了很多跨平台开发的优点,但它也有自己的缺点。而且看到很多二变为一,很容易认为是在减少,加上业界大厂分享的成功经验,更是验证这种想法。但我想强调具体情况具体分析,这里有一个很重要的点,我们所在的公司开发人员水平和大厂肯定是不一样的,所以它能取得成功,我们不一定能玩得转。所以当两套代码合并成一套,在大厂可能确实减少了开发和维护工作,但我们自己的情况可能就不一定了,因为这对开发人员的技术水平要求要高不少,这是需要考虑的一个问题。当我们在一些项目上使用跨平台技术开发时,如果能本着实事求是的态度,相信会更容易成功。有了这些认识,接下来,我们具体来看看跨平台开发技术。

当我们想跨平台时,我们就会寻找平台的共同之处,应该来讲目光很容易聚焦到 Web 技术上。移动端都可以使用 Web 技术,而且它在桌面端已经实现,可以说是一个不错的选择,于是就可以尝试从这里突破。本质上其实就是 Web 应用,我们要做是将设备的能力提供给 Web,Cordova 则是这方面的一个代表。

我认为移动端 Web 应用的主要问题还是性能,虽然现在硬件性能很强悍,但是很多 Web 应用和原生的体验还是有不小差别,所以这时就要权衡了。那能不能有个完美的解决方案呢?既然性能有问题,我们是不可以想办法优化性能,让它和原生体验一样?我认为 React Native 是顺着这种思路出现的,它使用 javascript 编码,最终设备上运行的是原生代码,即然是运行原生代码,性能自然可以做到和原生一致。虽然性能问题是解决了,但它需要用 javascript 编写多套代码,而且开发人员也要懂原生开发,或者有原生开发支持,不然遇到问题恐怕不好解决。

继续阅读

Web 界面布局

Web 应用程序是用户与软件系统的接口,用户通过她与系统进行交互。在 Web 应用程序的开发过程中,实现交互界面占工作内容的很大一部分比例,界面布局则又是这其中的重要组成部分,所以她值得我们花时间去掌握,以便完成工作任务,进而提高工作效率。

Web 诞生的背景是更好的共享信息,而这信息起初便是文字、图片。为了展示图文信息,涌现出了很多布局方式,一种称为流的布局方式在竞争中胜出了。

在这种布局方式中,界面元素被大体分为两类:一类是块级元素;另一类是是内联元素。块级元素负责结构布局,内联元素负责内容。在默认情况下,块级元素会像水流一样填满容器的宽度,内联元素则是从左至右,从上往下堆叠。很显然完全使用默认的布局行为是不能完成所有的需求的,于是在此基础上通过破坏流演化出新的布局行为,进而来满足我们的各种布局需求。所以总结下来,Web 的布局方法主要是如下几种:

  • 默认流布局行为
  • Float
  • Positioning
  • Table layout
  • Flexbox
  • Grid

界面布局的核心任务是控制界面元素的位置和大小。前面我们说过块级元素负责结构布局,所以位置主要是由她来控制。元素的布局信息是通过盒模型来表达的,下面是她的示意图:

margin 控制块元素间的间隙,padding 控制内容与块元素边框的间隙,所以可以用来控制位置。虽然 margin 是用来控制元素间的间隙,但我们通常可能希望将这种影响局部化,不然由于浏览器窗口大小变化,页面布局会受到很大影响,是与我们流布局的理念相挬的。因此她们主要是用在功能块内部。

在页面布局时,通常会将各功能用块元素包裹起来,这样可以简化布局工作。于是页面就由一棵元素树组成,类似下图:

在默认的流布局行为下,块元素的位置很有限,要么从布局容器的左上角开始,要么放在前一个块元素下面,这样恐怕不能完成多样的布局需求。只有拥有能布局到任意位置的能力,才能担此重任。于是需要借助 Positioning 和 Float 布局方法。

Positioning 布局方法是通过改变元素的 position 值来改变她的位置,她可能的值为:static | relative | absolute| fixed,static 是默认值,relative 是相对默认位置定位,absolute 是相对父元素中第一个不为 static 的元素定位,fixed 则是相对 viewport,这些属性大大增强了布局定位能力。

继续阅读