react.js开发
We can all likely agree on one thing: React is one of the most popular solutions out there for building interactive web applications, both small and large.
我们都可能在一件事情上达成共识:React是目前用于构建大小型交互式Web应用程序的最受欢迎的解决方案之一。
And it is used by so many startups and companies that it is a very valuable skill to have these days.
如此之多的初创公司和公司都在使用它,因此如今拥有这项技术是一项非常有价值的技能。
I discovered Next.js a couple of years back, and was intrigued with what it was trying to accomplish.
几年前,我发现了Next.js,并对它要完成的工作很感兴趣。
In this post, I'll describe my personal journey with Next.js. I'll also discuss why I believe that it is the right time to add it to your React stack.
在本文中,我将介绍Next.js的个人经历。 我还将讨论为什么我认为现在是将其添加到您的React堆栈的正确时机。
Back in the mid-2000s, when the web was young and growing, developers moved from static only HTML pages to more robust and dynamic solutions.
早在2000年代中期,网络还处于发展初期,开发人员就从仅静态HTML页面转向了更加健壮和动态的解决方案。
This gave us the ability to create pages with dynamic content using tech like PHP (mind you, JavaScript was very young and non-performant at this time).
这使我们能够使用PHP之类的技术创建具有动态内容的页面(请注意,JavaScript当时还很年轻并且性能不佳)。
You could have a single profile.php page and it would take care of Alice, Bob, John, Mehul, and all 15,000 registered people on your website – very convenient.
您可能只有一个profile.php页面,它可以照顾您网站上的Alice,Bob,John,Mehul和所有15,000名注册用户-非常方便。
Then came the JavaScript age. People started realizing that there was this language supported for the web which could be used for so much.
然后是JavaScript时代。 人们开始意识到,网络支持了这种语言,并且可以使用很多。
You could set up dynamic form submission, background HTTP requests, nice scrolling effects, and even create webpages on the fly.
您可以设置动态表单提交,后台HTTP请求,良好的滚动效果,甚至可以动态创建网页。
The rise of JavaScript and libraries like jQuery allowed web developers to create nice interfaces fully customizable with JavaScript.
JavaScript和jQuery之类的库的兴起使Web开发人员可以创建可通过JavaScript完全自定义的漂亮界面。
Soon, every web developer started pushing more and more JavaScript down the network to the client. Sure, technology evolved, mobile phones and PCs became better with more RAM and cores, but JavaScript started evolving faster.
很快,每个Web开发人员都开始将越来越多JavaScript通过网络推向客户端。 当然,随着技术的发展,具有更多RAM和内核的手机和PC变得更好,但是JavaScript开始发展得更快。
More functionalities, more features, and more frameworks meant a better user experience and the ability to create an app-like feeling on the web.
更多的功能,更多的功能和更多的框架意味着更好的用户体验以及在网络上创建类似应用程序的感觉的能力。
But this also meant pushing more and more JavaScript down the network on devices that could not keep up with evolving JavaScript limits.
但是,这也意味着将越来越多JavaScript推向无法跟上不断发展JavaScript限制的设备上的网络。
Old, slow mobile devices started giving up - load times became high, there was more lag, JS engines were less powerful, and there was just so much JavaScript to parse!
老式的,缓慢的移动设备开始放弃-加载时间变长,出现了更多的滞后,JS引擎的功能更弱,并且要解析JavaScript太多了!
With frameworks like React and Angular, you're basically pushing huge JavaScript bundles to clients which first have to download the small HTML pages.
使用React和Angular之类的框架,您基本上是在将巨大JavaScript捆绑包推送给客户端,这些客户端首先必须下载小HTML页面。
Web developers who moved from the PHP age (server-rendered HTML) to the JavaScript age (client rendered HTML) soon started realizing that they screwed up big time.
从PHP时代(服务器渲染HTML)过渡到JavaScript时代(客户端渲染HTML)的Web开发人员很快开始意识到,他们浪费了很多时间。
React was great for interactivity and high-performance components, but the fact that people starting using these tools to build everything started to create problems for clients.
React非常适合交互性和高性能组件,但是人们开始使用这些工具来构建一切的事实开始为客户带来问题。
A simple About Us page, which could be a very simple static HTML/CSS page, was now a page with a whopping JS bundle. The browser first had to download, then parse, then execute, and then change the DOM to display the content.
一个简单的关于我们页面,可能是一个非常简单的静态HTML / CSS页面,现在是一个包含大量JS捆绑包的页面。 浏览器首先必须下载,然后解析,然后执行,然后更改DOM以显示内容。
This was bad for everyone. Clients had higher load times. Browsers had to work hard to run JS (browsers parse and run HTML/CSS very efficiently). And search engines like Google and Bing had a hard time understanding what your page was about, because your source code never contained the real content. It was always embedded somewhere in your JS bundle.
这对每个人都是不好的。 客户的加载时间更长。 浏览器必须努力工作以运行JS(浏览器解析并非常有效地运行HTML / CSS)。 像Google和Bing这样的搜索引擎很难理解您的页面内容,因为您的源代码从不包含真实内容。 它总是嵌入在JS包中的某个位置。
People loved React and similar tools. But they also understood the implications of running too much JS client-side.
人们喜欢React和类似的工具。 但是他们也理解了过多运行JS客户端的含义。
On the other hand, they loved how PHP worked, but they didn't like its architecture. So what was the solution?
另一方面,他们喜欢PHP的工作方式,但是他们不喜欢它的体系结构。 那么解决方案是什么?
When developers realized that pushing too much React code on the client was a problem, they thought: Hey, is it possible to code in React, but ship HTML documents to clients?
当开发人员意识到在客户端上推送过多的React代码是一个问题时,他们认为:嘿,可以在React中进行编码,但可以将HTML文档发送给客户端吗?
After all, when the React code is done executing, all you really have is an HTML document anyway.
毕竟,当React代码完成执行后,您真正拥有的只是一个HTML文档。
So they did it. Server-Side Rendering (SSR) for React was born.
所以他们做到了。 用于React的服务器端渲染(SSR)诞生了。
Now, with SSR, you can write React code, somehow run it on the server (which was more powerful than your typical client device – like a mobile phone), and then send the HTML document to the client.
现在,使用SSR,您可以编写React代码,以某种方式在服务器上运行它(该功能比典型的客户端设备(如手机)功能强大),然后将HTML文档发送给客户端。
Win-win for everybody. You, as a developer, get to code in React - the technology you love. And the visitor on your site gets a plain HTML document (with visible content, and a little rehydrated JS), which gets a massive performance boost. Plus, Google loves you now.
为每个人双赢。 作为开发人员,您可以在React中进行编码-您喜爱的技术。 而且,您网站上的访问者会获得一个纯HTML文档(具有可见的内容和一些经过重新处理的JS),从而极大地提高了性能。 另外,Google现在爱您。
Who wouldn't want that?
谁不想要那个?
Server-side rendering definitely seemed like the solution to this problem. But the problem? It was too difficult to set up correctly.
服务器端渲染绝对似乎是解决此问题的方法。 但是问题呢? 正确设置太困难了。
Proper caching and cache-busting? Could you possibly create static HTML files for pages that didn't change? How should you build a seamless navigation experience on your website even if you have server-side rendered HTML? How should you ease down the load on your servers, or generate on-demand content?
适当的缓存和缓存清除? 您能否为未更改的页面创建静态HTML文件? 即使拥有服务器端呈现HTML,如何在网站上构建无缝的导航体验? 您应该如何减轻服务器的负载或生成按需内容?
And on top of all this, how do you set up this whole architecture? Sure, React and the web provides all the APIs for these, but they are quite verbose and usually a one-time setup.
最重要的是,您如何设置整个体系结构? 当然,React和Web提供了所有这些API,但是它们非常冗长,通常是一次性设置。
If you're someone who's actually building something valuable, after some time you would want the majority of your time to be spent on the business logic of your application, and not on the underlying logic.
如果您是真正在构建有价值的东西的人,那么一段时间后,您希望将大部分时间都花在应用程序的业务逻辑上,而不是基本逻辑上。
Next.js is a framework born in heaven. It ships with:
Next.js是天生的框架。 它附带:
It abstracts away all those performance and development setups you need with a typical React app and allows you to focus only on what matters – your business logic code.
它通过典型的React应用程序抽象出了您需要的所有性能和开发设置,并让您仅专注于重要的事情-业务逻辑代码。
I had my first experience with Next.js 2 years ago when it was very young.
2年前,我还没有使用Next.js的第一次经验。
But Next.js 9.5 was released this year with so many features. And I think it's safe to say that it is one of the most powerful tools available in the web development ecosystem, especially if you're a React developer.
但是Next.js 9.5今年发布了很多功能。 我认为可以肯定地说,它是Web开发生态系统中可用的最强大的工具之一,特别是如果您是React开发人员。
I run codedamn (a platform for developers to learn to code) myself on Next.js. There's a massive performance boost to the site compared to your regular React app.
我自己在Next.js上运行codedamn(开发人员可以学习编码的平台)。 与常规的React应用相比,该网站的性能得到了极大的提升。
If you're a React developer in 2020, one of the best skills you can learn is Next.js. Here are some benefits it offers you as a developer:
如果您是2020年的React开发人员,那么您可以学习的最佳技能之一就是Next.js. 以下是它为您提供的一些开发优势:
Next.js is evolving really fast. They deprecate old functionalities and introduce shiny new things all the time.
Next.js的发展非常Swift。 它们不赞成使用旧功能,并始终引入闪亮的新功能。
As of today, I'm super interested in the framework as a whole, but here are some of my top picks:
到今天为止,我对整个框架都非常感兴趣,但以下是一些我的首选:
Simply speaking, this feature allows you to generate static content dynamically. Wait, what? Let's see a quick example:
简而言之,此功能使您可以动态生成静态内容。 等一下 让我们看一个简单的例子:
Say you have a blog website (like this one) with a lot of articles. When somebody visits /news/[link]
(where [link]
is anything), you want to serve them the static page as fast as you can.
假设您有一个博客网站(像这样的网站),其中包含许多文章。 当有人访问/news/[link]
(其中[link]
任何内容)时,您希望尽快为他们提供静态页面。
But it is possible that you don't want to create all static pages at build time because it would take you a lot of time. In a few cases, this isn't possible at all at build time.
但是您可能不想在构建时创建所有静态页面,因为这会花费很多时间。 在某些情况下,在构建时根本不可能做到这一点。
Also, sometimes your content might change, like a quick blog edit - so you don't really want a completely static page forever either. So what's the solution?
另外,有时您的内容可能会发生变化,例如快速的博客编辑-因此,您也不希望永远都拥有完全静态的页面。 那么解决方案是什么?
Using Next.js 9.5+, now you can generate static pages dynamically to the dynamic path and refresh them.
使用Next.js 9.5+,现在您可以动态生成静态页面到动态路径并刷新它们。
This means that once Next fetches that particular URL, it'll save it as a static page and serve it statically whenever somebody visits the path. At the same time, it'll be open to accepting new paths dynamically.
这意味着,一旦Next提取了特定的URL,它将把它保存为静态页面,并在有人访问路径时静态地为其提供服务。 同时,它将对动态接受新路径开放。
Not only can you do this, with a revalidate parameter, you can also actually specify that Next.js should update your static pages once every X seconds in the background if there's any change!
您不仅可以使用revalidate参数来执行此操作,还可以实际指定Next.js如果有任何更改,则应在后台每隔X秒更新一次静态页面!
Next.js is heading towards Webpack 5 support too. This is exciting as Webpack 5 brings in some sweet performance and bundle optimizations and drops support for deprecated things in webpack 4, making the core lighter.
Next.js也正在向Webpack 5支持。 Webpack 5带来了一些不错的性能和包优化,并放弃了对Webpack 4中不推荐使用的东西的支持,这使内核变得更轻巧 ,这令人兴奋。
That means your Next.js apps will be faster than ever and more robust.
这意味着您的Next.js应用程序将比以往更快,更强大。
I personally didn't like the concept of having a single function execute on both environments - getInitialProps.
我个人不喜欢在两种环境中执行单个功能的概念-getInitialProps。
Thankfully, Next.js figured out that there's a much better solution available and they brought in getServerSideProps and getStaticProps as two great methods with good names.
值得庆幸的是,Next.js发现有一个更好的解决方案可用,他们引入了getServerSideProps和getStaticProps作为具有好名字的两种出色方法。
getServerSideProps
, as the name suggests, allows you to inject props in your Next.js page from the server itself. And getStaticProps
allows Next.js to still create static outputs at build time.
顾名思义, getServerSideProps
允许您从服务器本身在Next.js页面中注入道具。 getStaticProps
允许Next.js在构建时仍然创建静态输出。
getStaticProps
combined with incremental static regeneration is a killer feature in my opinion. You get the many benefits of a dynamic backend without having a dynamic backend.
我认为getStaticProps
与增量静态再生相结合是一个杀手级功能。 在没有动态后端的情况下,您可以获得动态后端的许多好处。
Next.js now also supports persistent caches for pages that are not changed. Before, when you shipped a new Next.js app, Next.js would throw out the whole app and the user had to download all the CSS/JS again, even if those bundles were unchanged.
Next.js现在还支持未更改页面的持久性缓存。 以前,当您交付新的Next.js应用程序时,Next.js会丢弃整个应用程序,并且即使这些捆绑包未更改,用户也必须再次下载所有CSS / JS。
In the latest version of Next.js released last week, our friends at Vercel introduced persistent caching which is again an absolutely great thing to have performance-wise.
在上周发布的最新版本的Next.js中,我们在Vercel的朋友介绍了持久性缓存,这对于性能方面来说绝对是一件很棒的事情。
If there's one thing I love more than JavaScript, it is TypeScript. And Sass is sweet too. Most people I know use Sass to power their CSS, and it provides a great developer experience.
如果我除了JavaScript之外还爱一件事,那就是TypeScript。 萨斯也很甜蜜。 我认识的大多数人都使用Sass来驱动CSS,它提供了出色的开发人员体验。
Next.js has long offered great support for TypeScript out of the box. But recently they added module based support for Sass as well.
长期以来,Next.js为TypeScript提供了出色的支持。 但是最近他们也为Sass添加了基于模块的支持 。
This means that your styles can now be written in Sass, local to your modules, with caching and revalidation - all managed by Next.js internally.
这意味着您现在可以在模块本地使用Sass编写样式,并进行缓存和重新验证-所有样式都由Next.js内部管理。
Seems like they really want you to develop the best products focusing only on the business logic.
好像他们真的希望您开发仅专注于业务逻辑的最佳产品。
I'm creating an exclusive video course on Next.js with best practices, latest framework updates, and super cool things you can do with it. I'm including a bunch of full projects with the framework so you'll get a deep understanding of how to work with this tool.
我正在Next.js上创建独家视频课程,其中包含最佳实践,最新框架更新以及您可以使用它完成的超酷工作。 我在框架中包含了很多完整的项目,因此您将对如何使用此工具有深入的了解。
If you're interested, sign up for early access using this Google form link and I'll make sure to reach out to you when it's out.
如果您有兴趣,请使用此Google表单链接注册抢先使用权,如果有兴趣,我们将确保与您联系。
I'm going all in on Next.js. The speed with which they're iterating and developing the SSR concept and making it available to so many is just astonishing.
我将全神贯注于Next.js。 他们迭代和开发SSR概念并将其提供给如此多的人的速度令人惊讶。
If you signed up using the form link above, expect to hear from me soon with some awesome content for you.
如果您使用上面的表单链接进行了注册,希望很快能收到我的来信,其中包含一些很棒的内容。
Feel free to hit me up on social media to share what you think: Twitter and Instagram.
随时在社交媒体上打扰我,分享您的想法: Twitter和Instagram 。
翻译自: https://www.freecodecamp.org/news/why-you-should-learn-next-js-as-a-react-developer/
react.js开发