在我看来，作为一个前端开发者，我们不仅仅是去执行产品设计下发下来的东西，更多的是要去思考什么样的设计/交互是好的，什么样的需求是合理的，成为一个有独立思考的开发者。
本篇是该系列第二季的第一集，介绍了Snackbar的使用场景（相信现在大部分的开发者使用的还只是Toast和Alert吧）。
正文
在你的应用中，交互信息的一个细节在于使用屏幕上的提示。但是，当那个信息很重要或者需要用户做决定的时候，你可能想要使用对话框(Alert)。
在过去，你有2种方式：
对话框。可以展示信息给用户，并让他们对其进行操作。
但是对话框是中断性的（强制用户停下正在做的，来处理你的对话框）。想想，你享受被打断的滋味吗？你喜欢那种去确认你想做的操作的感觉吗？还是喜欢弹出对话框？
这种交互很让人烦躁，不是么？
所以，对话框需要尽可能保守地去使用，这就让我们来到了第二种方式。
Toast
Toast可以确认用户做的事情确实发生了。
但如果这个操作是破坏性的呢，比如删除？
你的用户可能不想去那么做，而现在他们惊慌地在找怎么撤销，并对你在他删除那张美女图片前不进行再次确认而感到无语。卧槽，这是要干啥。
Snackbar就是为此而生的。
Snackbar和Toast类似，但它更强大，因为它是可交互的（比如提供你的用户正在找的撤销操作）。
Snackbar从屏幕底部浮起，用户可以将它划走，或者无视它（过一会自动消失，就像Toast那样）。Snackbar包含了一条短的信息，并能提供一个单一操作，比如撤销。
所以你现在有3种组件来帮助你使用最完美的方式来打断用户。
对话框：当用户的反应对你的app流程来说很重要，在这种时候你需要破坏性的干扰。
Toast：给用户一个不会改变任何东西的小提示。
Snackbar：前两者之间的区间内，Snackbar是你最好的朋友。
小结
对话框（Alerts）对于和用户交互来说是很重的一个操作，但它确实帮助你了解什么是恰当的，从而你的用户不会讨厌你。幸运的是，现在有了一个简单的回答：使用Snackbar!。
有一些微妙的场景，我们不知道如何在Toast和Snackbar之间抉择，那么Google的设计文档包括了你可能需要的所有的详尽细节。如果你仍然希望做错，Dialog当然也可以使用。但我们相信你能做得更好。所以成为一个更好的开发者，使用更好的选择：Snackbar。
最后牢骚一句，国内一些app退出的时候还要弹个Dialog问你是不是要退出的交互，真是够了/(ㄒoㄒ)/~~
随时随地看视频
