web高德maker動畫

by kushagra gour

由kushagra gour

Web Maker —我如何構建一個快速的離線前端游樂場 (Web Maker — How I built a fast, offline front-end playground)

Web Maker is a Chrome extension that gives you a blazing fast and offline front-end playground — right inside your browser.

Web Maker是一個Chrome擴展程序，可讓您在瀏覽器內部快速，離線地訪問前端平臺。

It’s used daily by thousands of developers around the world and has a 5 star rating from 700+ users. It was also a homepage featured extension on the Chrome Webstore, twice!

全球每天有成千上萬的開發人員在使用它，并獲得700多個用戶的5星評級 。 這也是Chrome Webstore上首頁功能擴展的兩倍！

You can use Web Maker to play with HTML, CSS and JavaScript right in the browser without any external editor or specific setup. You can use things like Angular, React, Sass, Babel, or Atomic CSS — just like that.

您可以使用Web Maker在瀏覽器中直接播放HTML，CSS和JavaScript，而無需任何外部編輯器或特定設置。 您可以使用Angular，React，Sass，Babel或Atomic CSS之類的東西。

為什么我做網絡制造商 (Why I made web maker)

If you’re a front-end developer, you’ve probably tried one or more of the code playgrounds out there — like CodePen, JSBin, JSFiddle — to figure out code issues or to discuss snippets and logic pieces with colleagues.

如果您是前端開發人員，則可能已經嘗試過一個或多個代碼游樂場(例如CodePen，JSBin，JSFiddle)來找出代碼問題或與同事討論代碼片段和邏輯部分。

They’re all great and do the job perfectly.

他們都很出色，可以完美地完成工作。

But I’ve always felt a slight friction in using them over the internet — there’s an inherent delay between starting them up and being able to use them.

但是我一直感覺到在Internet上使用它們時會遇到一些摩擦-在啟動它們和使用它們之間存在固有的延遲。

I also wanted a quick way to hack stuff while traveling or waiting at the airport, where you’re mostly offline. I could go with traditional editor and browser thing, but that requires a bit of setup.

我還希望有一種快速的方法來旅行或在機場(大多數情況下都處于離線狀態)等待時破解東西。 我可以使用傳統的編輯器和瀏覽器，但這需要一些設置。

When I thought more about it, I realized there are many places in the world with limited or no internet connectivity at all. People who want to learn and do web development there can’t use these online playgrounds. That shouldn’t stop them from learning and creating things!

當我對此進行更多思考時，我意識到世界上有很多地方根本沒有互聯網連接，或者根本沒有互聯網連接。 想要學習和進行Web開發的人不能使用這些在線游樂場。 那不應該阻止他們學習和創造東西！

I tried looking for something that could give me what I wanted, but couldn’t find any. And so Web Maker was born.

我試圖尋找可以滿足我需求的東西，但找不到任何東西。 因此，Web Maker誕生了。

我是如何制作Web Maker的 (How I made Web Maker)

The initial version of Web Maker was very basic. It had three editable sections (which were CodeMirror instances) for HTML, CSS, and JavaScript each. Whenever code was updated, it was combined into an HTML string with everything placed inline. This HTML string was then dumped inside an iframe document and rendered.

Web Maker的初始版本非常基礎。 它有三個可編輯部分(分別是CodeMirror實例)，分別用于HTML，CSS和JavaScript。 每當更新代碼時，它就會組合成一個HTML字符串，所有內容都內聯。 然后將此HTML字符串轉儲到iframe文檔中并進行呈現。

This process has changed over time and multiple features have shipped since then. There are many interesting decisions, features, logic pieces and challenges that I’ll share in this article.

此后，此過程已發生變化，并且此后已發布了多個功能。 我將在本文中分享許多有趣的決策，功能，邏輯部分和挑戰。

Chrome擴展程序-終極發行平臺 (Chrome extension — the ultimate distribution platform)

I wanted a very simple distribution platform for Web Maker since it was in early stages. I also wanted something with a wide reach, so I chose to make it a Chrome extension.

因為Web Maker處于早期階段，所以我希望它提供一個非常簡單的發行平臺。 我還想要范圍廣泛的產品，因此我選擇將其作為Chrome擴展程序。

The Chrome Web Store is a breeze to use. Pushing an update is very easy and quick. The Chrome extension platform also offers capabilities that can be leveraged into interesting features. One example in Web Maker is screenshot capture of preview. It uses the captureVisibleTab API to grab the preview iframe’s screenshot and then the downloads API to download it for you with a click of a button.

Chrome網上應用店輕而易舉地使用。 推送更新非常簡單快捷。 Chrome擴展程序平臺還提供了可以利用為有趣功能的功能。 Web Maker中的一個示例是預覽的屏幕截圖捕獲。 它使用captureVisibleTab API來獲取預覽iframe的屏幕截圖，然后使用downloads API只需單擊一下按鈕即可為您下載它。

用香草JavaScript和CSS編寫 (Written in vanilla JavaScript and CSS)

I have worked with JavaScript frameworks like Angular and Vue in small and large-scale applications. I could have used any of the available frameworks here too. But for Web Maker I decided to go vanilla to challenge myself and see how far could I go without a framework until the codebase becomes spaghetti. I wanted to use all the knowledge I have gained from working with those frameworks and libraries to keep the code sane, organized and DRY.

我曾經在小型和大型應用程序中使用過像Angular和Vue這樣JavaScript框架。 我也可以在這里使用任何可用的框架。 但是對于Web Maker，我決定去挑戰自己，看看沒有框架的情況下我能走多遠，直到代碼庫成為意大利面條為止。 我想利用從這些框架和庫中獲得的所有知識來使代碼保持理智，有條理和干燥。

As most projects do, I started with a single script.js JavaScript file. To keep the codebase modular and organized, I moved big independent chunks out of it into separate files as needed (for example, utils.js and dropdown.js).

與大多數項目一樣，我從一個script.js JavaScript文件開始。 為了使代碼庫保持模塊化和井井有條，我根據需要將較大的獨立塊移出了單獨的文件(例如utils.js和dropdown.js )。

Apart from that I also wrote a small directive system (like in angular/Vue) that lets me do things like:

除此之外，我還編寫了一個小型指令系統(例如angular / Vue)，可以執行以下操作：

<a class=”btn” d-click=”someFunction”>Button</a>

and

和

<input d-change=”someOtherFunction” >

Note: I couldn’t use inline scripts like onclick or onchange. They’re not allowed in Chrome extensions due to security restrictions.

注意：我無法使用諸如onclick或onchange類的內聯腳本。 由于安全限制，Chrome擴展程序中不允許使用它們。

For CSS too, Web Maker only relies on browser provided features like CSS variables. Since I developed Web Maker just for Chrome, I can safely use new upcoming features without worrying about cross browser support — another perk of building a Chrome extension.

對于CSS而言，Web Maker也僅依靠瀏覽器提供的功能(如CSS變量)。 由于我僅針對Chrome開發了Web Maker，因此我可以安全地使用即將推出的新功能，而不必擔心跨瀏覽器支持-構建Chrome擴展程序的另一個好處。

I plan to look into web components to break the UI into independent components.

我計劃研究Web組件，以將UI分成獨立的組件。

預覽生成 (Preview generation)

As I mentioned earlier, in the first version of the app, the final preview was simply an HTML string which had user’s CSS as an inlined style tag and user’s JavaScript as inlined script tag. And this HTML string was written in a temporary HTML file which loaded in an iframe. The HTML file looked something like this:

正如我前面提到的，在該應用程序的第一個版本中，最終預覽只是一個HTML字符串，其中包含用戶CSS作為內嵌樣式標簽，而用戶JavaScript作為內嵌腳本標簽。 然后，此HTML字符串寫入了一個臨時HTML文件中，該文件已加載到iframe中。 HTML文件如下所示：

<html> <head> <style> user CSS here... </style> </head> <body> user html here... <script>user JS here...</script> </body></html>

But while working on the version 2.0 of Web Maker I found that on Chrome Canary (v57 at the time) the preview was no longer running the user’s JavaScript. Upon inspection, I found a chrome policy error in the developer console that said:

但是，在使用Web Maker 2.0版時，我發現在Chrome Canary(當時為v57)上，預覽不再運行用戶JavaScript。 經過檢查，我在開發人員控制臺中發現了一個chrome策略錯誤，內容為：

Refused to execute inline script because it violates the following Content Security Policy directive…拒絕執行內聯腳本，因為它違反了以下內容安全策略指令…

Now, I already knew that the Content Security Policy (CSP) didn’t allow me to put inline scripts into a Chrome extension’s markup, and I had all my JavaScript in separate files. This was different. Starting with Chrome 57, the CSP had started applying to preview iframes, too. The solution was to move the user’s JavaScript from inline to a separate JavaScript file.

現在，我已經知道內容安全策略(CSP)不允許我將內聯腳本放入Chrome擴展程序的標記中，并且我所有JavaScript都放在單獨的文件中。 這是不同的。 從Chrome 57開始，CSP也開始應用到預覽iframe。 解決方案是將用戶JavaScript從內聯移動到單獨JavaScript文件。

So I refactored the logic and now on every refresh, the user’s JavaScript is written into a temporary JavaScript file. This is then loaded in the preview iframe.

因此，我重構了邏輯，現在每次刷新時，用戶JavaScript都會寫入一個臨時JavaScript文件中。 然后將其加載到預覽iframe中。

Note that the preview iframe isn’t refreshed on every keystroke in the editor. The refresh is debounced on user input — so the preview is only refreshed when the user has stopped typing for a short duration. Otherwise, it would result in a lot of unnecessary refreshes as the user is typing.

請注意，并不是在編輯器中的每次擊鍵操作時都刷新預覽iframe。 刷新將在用戶輸入時被消除抖動 -因此，僅當用戶在短時間內停止鍵入時，刷新預覽。 否則，這將導致在用戶鍵入時出現許多不必要的刷新。

CSS updating is a little different though. Unlike HTML and JavaScript where the complete iframe is refreshed, CSS updates whenever it’s edited in the style tag of the iframe. There is no file writing or iframe refresh involved. Hence, for CSS, the preview refresh is a lot faster.

CSS更新有些不同。 與刷新完整iframeHTML和JavaScript不同的是，只要在iframe的樣式標簽中對其進行編輯，CSS就會更新。 不涉及文件寫入或iframe刷新。 因此，對于CSS，預覽刷新要快得多。

JavaScript中的無限循環預防 (Infinite loop prevention in JavaScript)

As I mentioned above, the preview refreshes as soon as the user stops typing. At this point, it’s possible that user paused while writing a loop in JavaScript, resulting in a partial form. Something like:

如上所述，用戶停止鍵入后，預覽就會刷新。 此時，用戶可能會在用JavaScript編寫循環時暫停，從而導致部分形式。 就像是：

for (var i = 0; i<10; [user_cursor_here]) {}

The increment/decrement condition is missing from this JavaScript — so if it was put inside the iframe, the browser tab would choke! Such cases need to be prevented by any playground like Web Maker.

此JavaScript中缺少遞增/遞減條件-因此，如果將其放在iframe中，則瀏覽器選項卡會阻塞！ Web Maker等任何游樂場都需要防止此類情況。

Web Maker does this by parsing user’s JavaScript and modifying all the loops so that each loop keeps checking if it hasn’t taken too long to run.

Web Maker通過解析用戶JavaScript并修改所有循環來做到這一點，以便每個循環都可以檢查它是否花了很長時間才運行。

Basically, this:

基本上，這是：

for (var i = 0; i<10; [user_cursor_here]) {}

is converted to:

轉換為：

var _wmloopvar1 = Date.now();for (var i = 0; i<10; [user_cursor_here]) { if (Date.now() - _wmloopvar1 > 1000) { break; }\}

If we spend more than a second inside a loop, we break and come out.

如果我們在一個循環中花費超過一秒鐘的時間，我們就會中斷并出來。

I use Esprima for all this instrumentation. Here is a detailed blog post on how it’s done. Note, the logic mentioned in the blog post was recently refactored to be more efficient, as suggested by Esprima’s author Ariya Hidayat.

我將Esprima用于所有這些工具。 這是有關如何完成的詳細博客文章 。 注意，正如Esprima的作者Ariya Hidayat所建議的那樣，博客文章中提到的邏輯最近被重構為更有效。

預處理器 (Preprocessors)

Like most front-end playground, Web Maker gives many preprocessors for each HTML, CSS, and JavaScript.

像大多數前端游樂場一樣，Web Maker為每種HTML，CSS和JavaScript提供了許多預處理器。

Adding any preprocessor in the app requires getting hold of its transpiler (source-to-source compiler) and understanding how it transpiles the input code. You also need to know that it displays transpilation errors besides every line.

在應用程序中添加任何預處理器都需要掌握其編譯器(源到源編譯器)并了解其如何編譯輸入代碼。 您還需要知道，除每行外，它還會顯示翻譯錯誤。

Now almost all of the online playgrounds out there transpile your code on their server. But Web Maker has no server — it sits in your browser and runs in your browser.

現在，幾乎所有的在線游樂場都在您的服務器上轉換您的代碼。 但是Web Maker沒有服務器-它位于您的瀏覽器中并在您的瀏覽器中運行。

Many transpilers are meant to be run only in a NodeJS environment, so I made an effort to bundle them into browser compatible code. Web Maker uses transpilers like CoffeeScript, SASS, and Babel.

許多編譯器只應在NodeJS環境中運行，因此我努力將它們捆綁到瀏覽器兼容的代碼中。 Web Maker使用諸如CoffeeScript ， SASS和Babel的編譯器。

Upon every change in the editor, the user’s code is sent to the appropriate transpiler, and then the transpiled code is sent to preview generation. I used a Promise based API for transpiling code for two reasons:

在編輯器中進行每次更改后，都會將用戶代碼發送到適當的編譯器，然后將已編譯的代碼發送到預覽生成。 我使用基于Promise的API進行代碼轉換有兩個原因：

SASS transpiler is not synchronous. It uses a worker to convert the SASS code to CSS on a separate thread.

SASS編譯器不同步。 它使用工作程序在單獨的線程上將SASS代碼轉換為CSS。

I might move other transpilers to a separate worker too. Source compilation can sometimes take a long time. It can also result in infinite loops, blocking the main UI thread in such cases. Thus it’s better to move them to separate worker.

我也可能將其他編譯器也轉移到單獨的工作人員那里。 源代碼編譯有時可能需要很長時間。 在這種情況下，它還會導致無限循環，從而阻塞主UI線程。 因此，最好將它們移到單獨的工人上。

For example, the function that converts JavaScript looks like this in a broad sense:

例如，轉換JavaScript的函數在廣義上如下所示：

function computeJs() { var d = deferred(); if (jsMode === JsModes.COFFEESCRIPT) { try { code = CoffeeScript.compile(code, { bare: true }); } catch (e) { showErrors( 'js', [{ lineNumber: e.location.first_line, message: e.message }] ); } finally { d.resolve(code); }}

存儲 (Storage)

Version 2.0 of Web Maker shipped with a very important capability to store user creations.

Web Maker 2.0版附帶了非常重要的功能來存儲用戶創建的內容。

I decided to use localStorage. So, even if you are working on a different machine you can save all your Web Maker settings like indentation size, theme etc.

我決定使用localStorage 。 因此，即使您在其他計算機上工作，也可以保存所有Web Maker設置，例如縮進大小，主題等。

It would have been great if even the creations were stored in synced storage like the extension’s settings. That way they’d be accessible across devices. Synced storage come with comparatively lower space quota, however, and I didn’t want to risk the saved work.

如果將創建內容(例如擴展程序的設置)存儲在同步存儲中，那就太好了。 這樣，就可以跨設備訪問它們。 但是，同步存儲具有相對較低的空間配額，我不想冒險保存工作。

You may be able to save all your work on the cloud in future versions!

您也許可以在將來的版本中將所有工作保存在云中！

Web Maker also has an option to export and import all the saved creations.

Web Maker還可以選擇導出和導入所有保存的創建。

基于開放式Web技術和開放源代碼庫 (Built on open web technologies and open-source libraries)

Web Maker is build over multiple awesome open source libraries and is itself open source.

Web Maker建立在多個很棒的開源庫之上，并且它本身就是開源的 。

The three editor panes where you actually type the code is is built with CodeMirror. CodeMirror comes with a lot of add-ons and modes, which allows Web Maker to support code autocompletion, code folding, syntax highlighting, and themes.

您在其中實際鍵入代碼的三個編輯器窗格是使用CodeMirror構建的 。 CodeMirror帶有許多附加組件和模式，這使Web Maker可以支持代碼自動完成，代碼折疊，語法突出顯示和主題。

Thanks to Esprima, you can see generic JavaScript errors in your code as you type in the editor. As I mentioned before, Esprima also helps prevent infinite loops.

多虧了Esprima ，您在編輯器中鍵入代碼時就可以看到代碼中的一般JavaScript錯誤。 如前所述，Esprima還有助于防止無限循環。

Apart from that Web Maker uses Split.js, Hint.css, Emmet, Inlet.js, and even Web Maker! Yes, Web Maker is made inside Web Maker.

除此之外，Web Maker還使用Split.js ， Hint.css ， Emmet ， Inlet.js甚至Web Maker！ 是的，Web Maker是在Web Maker內部制作的。

挑戰性 (Challenges)

There were many slowdowns during the development, but I would like to talk about two major ones.

在開發過程中有許多放慢的速度，但是我想談談兩個主要的放慢速度。

As I mentioned, when I was working on version 2.0, I discovered a major change in Chrome 57 which broke the ability to put inline scripts into the extension’s markup.

正如我所提到的，當我使用2.0版時，我發現Chrome 57發生了重大變化，這打破了將內聯腳本放入擴展的標記中的功能。

There was also a feature shipped with 2.0 that allowed the user to add any number of external JavaScript or CSS libraries. When the user enters a JavaScript library URL, it is added as a script tag with the src attribute set to the URL. Chrome extension CSP, apart from preventing inline JavaScript, also restricts JavaScript from loading domains except those mentioned in the CSP — which meant that user won’t be able to load external JavaScript from any random domain.

2.0附帶的功能還允許用戶添加任意??數量的外部JavaScript或CSS庫。 當用戶輸入JavaScript庫URL時，它將添加為src屬性設置為URL的腳本標記。 Chrome擴展程序CSP除了阻止內聯JavaScript外，還限制了JavaScript無法加載CSP中提到的域之外的域-這意味著用戶將無法從任何隨機域中加載外部JavaScript。

This is currently partially solved by whitelisting all the major CDNs in the manifest.json file. It’s still not perfect as user cannot load JavaScript from any domain apart from those.

目前，這可以通過將manifest.json文件中的所有主要CDN列入白名單來部分解決。 由于用戶無法從任何域中加載JavaScript，因此它仍然不是完美的。

Another big thing that hit me was the Preview Screenshot feature. This feature allows the user to grab a screenshot of the current preview and download it as an image with a click of a button. This feature required me to bring in two more permissions: downloads and <all_urls>.

讓我大吃一驚的是預覽屏幕截圖功能。 此功能使用戶可以捕獲當前預覽的屏幕快照，然后單擊按鈕即可將其下載為圖像。 此功能要求我再添加兩個權限： downloads和<all_ur ls>。

&lt;all_urls> is actually a weird permission, but it’s a must-have if you want to use the captureVisibleTab API. Here’s how it looks while installing the extension:

＆ lt;all_ur ls>實際上是一個奇怪的權限，但是如果您要e the captureVisi bleTab API， e the captureVisi必不可少的。 安裝擴展程序時的外觀如下：

The first line is pretty scary for anyone installing the extension.

對于安裝此擴展程序的任何人，第一行都非常可怕。

Additionally, if you add a new permission for a new version of an extension, Chrome disables the installed extension and shows a popup that the extension requires new permission.

此外，如果您為新版本的擴展程序添加新權限，Chrome會禁用已安裝的擴展程序，并顯示一個彈出窗口，提示該擴展程序需要新權限。

This alarmed some users who already had Web Maker installed. Many people who saw this new permission being asked, didn’t allow it, and uninstalled it right away.

這使一些已經安裝了Web Maker的用戶感到震驚。 許多看到此新許可的人都被要求，不允許這樣做并立即將其卸載。

After this particular release, I saw a big spike in the number of uninstalls.

在此特定發行版之后，我看到卸載數量激增。

The moral of the story: Be careful with the permissions you add to your app. Unless required for core-functioning, always go for optional in-app permissions.

故事的寓意：小心添加到應用程序中的權限。 除非核心功能需要，否則請務必獲得可選的應用內權限。

總結一下 (Summing it up)

Web Maker has come quite far in terms of usability, features, and adoption. Being quick and offline makes it usable in huge number of scenarios, from doing web experiments on a train/plane to teaching a classroom of students.

Web Maker在可用性，功能和采用方面取得了很大進步。 快速且離線使它可用于大量場景，從在火車/飛機上進行網絡實驗到為學生教室授課。

Web Maker can also be used by professionals and beginners in areas where the internet is slow or not present at all.

專業人士和初學者也可以在互聯網速度緩慢或根本沒有互聯網的地區使用Web Maker。

And I am sure Web Maker can help FreeCodeCamp campers tremendously in their learnings and practice.

而且我確信Web Maker可以極大地幫助FreeCodeCamp營員的學習和實踐。

Moreover, Web Maker is open-source, so everyone is welcome to suggest and implement features they think would make it more useful. It could be your first step to learn some practical JavaScript by contributing.

此外，Web Maker是開源的 ，因此歡迎每個人提出并實施他們認為會使其更有用的功能。 通過貢獻力量學習一些實用JavaScript可能是您的第一步。

If you have any suggestions, comments or questions, tweet them @webmakerApp. I am excited to hear your feedback and experience with it.

如果您有任何建議，意見或問題，請在@webmakerApp上發布 。 我很高興聽到您的反饋和使用經驗。

Install Web Maker and give it a spin and follow Web Maker on Medium for tips, tricks and how-to articles.

安裝Web Maker并試用一下，然后在Medium上關注Web Maker ，獲取提示，技巧和操作方法文章。

翻譯自: https://www.freecodecamp.org/news/web-maker-how-i-built-a-fast-offline-front-end-playground-9fe3629bc86f/

web高德maker動畫

總結

以上是生活随笔為你收集整理的web高德maker动画_Web Maker —我如何构建一个快速的离线前端游乐场的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。