Hello World

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 的布局方法主要是如下几种：

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

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

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

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

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

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