Each language server can be installed via a package manager - but often in a different way. For example, the language servers for HTML/CSS/JS are provided by Microsoft, and are installed via npm. Whereas the language server for say, Rust, might be managed by rustup (or Rust itself). Keep this in mind, as you will need to have the relevant package manager installed based on what language servers you need. Microsoft keeps a list of LSP servers where you can check the repositories to see which package manager (if any) you will need to install it.

Mason is an easy way to install these language servers for the programming languages of your choice if you don’t want to install and maintain them yourself.

It’s worth noting that these features don’t technically ship directly with Neovim when the language server is configured. It enables the use of them, and you have to get plugins for each feature you want (unix philosophy, baby).

These servers make it possible to get features such as go-to-definition, auto-complete and syntax errors (like if you spell something wrong or miss a semi-colon - so you don’t rip your hair out trying to find it).

Neovim ships with a built-in LSP client,

When picking a Neovim colorscheme make sure that it’s tree-sitter supported/compatible - Awesome Neovim provides a list of themes which you can use.

For example, creating a file called lazy.lua and then requiring it in your init.lua with require("lazy") is going to cause some problems... Remember the snippet above does the exact same thing to find lazy on the runtimepath, but now there are two modules named lazy - one in your config, and one in the Neovim data directory. This will essentially cause your entire configuration to break.

I hope that you at least found this post useful though in understanding the runtimepath and which files are automatically ran on startup, why people structure their lua/ folders in different ways, and how you can begin structuring your configuration.

The reason you tend to see most users throwing their entire config in the lua/ directory is because you can use Lua modules to organize your config in a nice, neat way.

Control characters other than tab (U+0000 to U+0008, U+000A to U+001F, U+007F) are not permitted in comments.

Newline means LF (0x0A) or CRLF (0x0D 0x0A).

TOML is designed to map unambiguously to a hash table.

There are also other use cases for refs than accessing React components.

The function that creates the component is wrapped inside of a forwardRef function call. This way the component can access the ref that is assigned to it. The component uses the useImperativeHandle hook to make its toggleVisibility function available outside of the component. We can now hide the form by calling noteFormRef.current.toggleVisibility() after a new note has been created:

The useRef hook is used to create a noteFormRef reference, that is assigned to the Togglable component containing the creation note form. The noteFormRef variable acts as a reference to the component. This hook ensures the same reference (ref) that is kept throughout re-renders of the component.

React documentation says the following about where to place the state: Sometimes, you want the state of two components to always change together. To do it, remove state from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as lifting state up, and it’s one of the most common things you will do writing React code. If we think about the state of the forms, so for example the contents of a new note before it has been created, the App component does not need it for anything. We could just as well move the state of the forms to the corresponding components.

The new and interesting part of the code is props.children, which is used for referencing the child components of the component. The child components are the React elements that we define between the opening and closing tags of a component.

If loginVisible is false, then display will not receive any value related to the visibility of the component.

No matter how the validity of tokens is checked and ensured, saving a token in the local storage might contain a security risk if the application has a security vulnerability that allows Cross Site Scripting (XSS) attacks. An XSS attack is possible if the application would allow a user to inject arbitrary JavaScript code (e.g. using a form) that the app would then execute. When using React sensibly it should not be possible since React sanitizes all text that it renders, meaning that it is not executing the rendered content as JavaScript. If one wants to play safe, the best option is to not store a token in local storage. This might be an option in situations where leaking a token might have tragic consequences. It has been suggested that the identity of a signed-in user should be saved as httpOnly cookies, so that JavaScript code could not have any access to the token. The drawback of this solution is that it would make implementing SPA applications a bit more complex. One would need at least to implement a separate page for logging in. However, it is good to notice that even the use of httpOnly cookies does not guarantee anything. It has even been suggested that httpOnly cookies are not any safer than the use of local storage. So no matter the used solution the most important thing is to minimize the risk of XSS attacks altogether.

The empty array as the parameter of the effect ensures that the effect is executed only when the component is rendered for the first time.

Values saved to the storage are DOMstrings, so we cannot save a JavaScript object as it is. The object has to be parsed to JSON first, with the method JSON.stringify. Correspondingly, when a JSON object is read from the local storage, it has to be parsed back to JavaScript with JSON.parse.

Values in the local storage are persisted even when the page is re-rendered. The storage is origin-specific so each web application has its own storage.

This problem is easily solved by saving the login details to local storage. Local Storage is a key-value database in the browser.

The noteService module contains a private variable called token. Its value can be changed with the setToken function, which is exported by the module. create, now with async/await syntax, sets the token to the Authorization header. The header is given to axios as the third parameter of the post method.

A slightly odd looking, but commonly used React trick is used to render the forms conditionally:

This is most likely useful when doing the fix.

the field blog.user does not contain a string, but an object. So if you want to compare the ID of the object fetched from the database and a string ID, a normal comparison operation does not work. The ID fetched from the database must be parsed into a string first.

Both the new blog creation and blog deletion need to find out the identity of the user who is doing the operation. The middleware tokenExtractor that we did in exercise 4.20 helps but still both the handlers of post and delete operations need to find out who the user holding a specific token is.

As can be seen, this happens by chaining multiple middlewares as the arguments of the function use. It would also be possible to register a middleware only for a specific operation:

NB if you decide to define tests on multiple files, you should note that by default each test file is executed in its own process (see Test execution model in the documentation). The consequence of this is that different test files are executed at the same time. Since the tests share the same database, simultaneous execution may cause problems, which can be avoided by executing the tests with the option --test-concurrency=1, i.e. defining them to be executed sequentially.

Usernames, passwords and applications using token authentication must always be used over HTTPS. We could use a Node HTTPS server in our application instead of the HTTP server (it requires more configuration). On the other hand, the production version of our application is in Fly.io, so our application stays secure: Fly.io routes all traffic between a browser and the Fly.io server over HTTPS.

Limiting creating new notes to logged-in users

It is also quite usual that instead of using Authorization-header, cookies are used as the mechanism for transferring the token between the client and the server.

When server-side sessions are used, the token is quite often just a random string, that does not include any information about the user as it is quite often the case when jwt-tokens are used. For each API request, the server fetches the relevant information about the identity of the user from the database.

The negative aspect of server-side sessions is the increased complexity in the backend and also the effect on performance since the token validity needs to be checked for each API request to the database. Database access is considerably slower compared to checking the validity of the token itself. That is why it is quite common to save the session corresponding to a token to a key-value database such as Redis, that is limited in functionality compared to eg. MongoDB or a relational database, but extremely fast in some usage scenarios.

The other solution is to save info about each token to the backend database and to check for each API request if the access rights corresponding to the tokens are still valid. With this scheme, access rights can be revoked at any time. This kind of solution is often called a server-side session.

Once the token expires, the client app needs to get a new token. Usually, this happens by forcing the user to re-login to the app. The error handling middleware should be extended to give a proper error in the case of an expired token

Token authentication is pretty easy to implement, but it contains one problem. Once the API user, eg. a React app gets a token, the API has a blind trust to the token holder. What if the access rights of the token holder should be revoked?

If the application has multiple interfaces requiring identification, JWT's validation should be separated into its own middleware. An existing library like express-jwt could also be used.

The helper function getTokenFrom isolates the token from the authorization header. The validity of the token is checked with jwt.verify. The method also decodes the token, or returns the Object which the token was based on.

There are several ways of sending the token from the browser to the server. We will use the Authorization header. The header also tells which authentication scheme is used. This can be necessary if the server offers multiple ways to authenticate. Identifying the scheme tells the server how the attached credentials should be interpreted.

If the password is correct, a token is created with the method jwt.sign. The token contains the username and the user id in a digitally signed form.

ecause the passwords themselves are not saved to the database, but hashes calculated from the passwords, the bcrypt.compare method is used to check if the password is correct:

Let's first implement the functionality for logging in. Install the jsonwebtoken library, which allows us to generate JSON web tokens.

The principles of token-based authentication are depicted in the following sequence diagram:

We will now implement support for token-based authentication to the backend.

NOTE: At this stage, firstly, some tests will fail. We will leave fixing the tests to a non-compulsory exercise.

We could also implement other validations into the user creation. We could check that the username is long enough, that the username only consists of permitted characters, or that the password is strong enough. Implementing these functionalities is left as an optional exercise.

However, we want to be careful when using the uniqueness index. If there are already documents in the database that violate the uniqueness condition, no index will be created. So when adding a uniqueness index, make sure that the database is in a healthy state! The test above added the user with username root to the database twice, and these must be removed for the index to be formed and the code to work.

The fundamentals of storing passwords are outside the scope of this course material. We will not discuss what the magic number 10 assigned to the saltRounds variable means, but you can read more about it in the linked material.

It's important to understand that the database does not know that the ids stored in the user field of the notes collection reference documents in the user collection. The functionality of the populate method of Mongoose is based on the fact that we have defined "types" to the references in the Mongoose schema with the ref option:

We can use the populate method for choosing the fields we want to include from the documents. In addition to the field id we are now only interested in content and important. The selection of fields is done with the Mongo syntax:

The argument given to the populate method defines that the ids referencing note objects in the notes field of the user document will be replaced by the referenced note documents.

Mongoose library can do some of these joins for us. Mongoose accomplishes the join by doing multiple queries, which is different from join queries in relational databases which are transactional, meaning that the state of the database does not change during the time that the query is made. With join queries in Mongoose, nothing can guarantee that the state between the collections being joined is consistent, meaning that if we make a query that joins the user and notes collections, the state of the collections may change during the query.

Mongoose validations do not provide a direct way to check the uniqueness of a field value. However, it is possible to achieve uniqueness by defining uniqueness index for a field. The definition is done as follows:

In stark contrast to the conventions of relational databases, references are now stored in both documents: the note references the user who created it, and the user has an array of references to all of the notes created by them.

The type of the field is ObjectId that references note-style documents. Mongo does not inherently know that this is a field that references notes, the syntax is purely related to and defined by Mongoose.

The structure and schema of the database are not as self-evident as it was with relational databases. The chosen schema must support the use cases of the application the best. This is not a simple design decision to make, as all use cases of the applications are not known when the design decision is made. Paradoxically, schema-less databases like Mongo require developers to make far more radical design decisions about data organization at the beginning of the project than relational databases with schemas. On average, relational databases offer a more or less suitable way of organizing data for many applications.

The then-chain is alright, but we can do better. The generator functions introduced in ES6 provided a clever way of writing asynchronous code in a way that "looks synchronous". The syntax is a bit clunky and not widely used.

The documentation for supertest says the following: if the server is not already listening for connections then it is bound to an ephemeral port for you so there is no need to keep track of ports. In other words, supertest takes care that the application being tested is started at the port that it uses internally.

The Promise.all method can be used for transforming an array of promises into a single promise, that will be fulfilled once every promise in the array passed to it as an argument is resolved. The last line of code await Promise.all(promiseArray) waits until every promise for saving a note is finished, meaning that the database has been initialized.

Promise.all executes the promises it receives in parallel. If the promises need to be executed in a particular order, this will be problematic. In situations like this, the operations can be executed inside of a for...of block, that guarantees a specific execution order.

The problem is that every iteration of the forEach loop generates an asynchronous operation, and beforeEach won't wait for them to finish executing. In other words, the await commands defined inside of the forEach loop are not in the beforeEach function, but in separate functions that beforeEach will not wait for.

Because of the library, we do not need the next(exception) call anymore. The library handles everything under the hood. If an exception occurs in an async route, the execution is automatically passed to the error-handling middleware.

One starts to wonder if it would be possible to refactor the code to eliminate the catch from the methods? The express-async-errors library has a solution for this.

The reason for this is that strictEqual uses the method Object.is to compare similarity, i.e. it compares whether the objects are the same. In our case, it is enough to check that the contents of the objects, i.e. the values of their fields, are the same. For this purpose deepStrictEqual is suitable.

When code gets refactored, there is always the risk of regression, meaning that existing functionality may break.

The await keyword can't be used just anywhere in JavaScript code. Using await is possible only inside of an async function.

The async and await keywords introduced in ES7 bring the same functionality as the generators, but in an understandable and syntactically cleaner way to the hands of all citizens of the JavaScript world.

By chaining promises we could keep the situation somewhat under control, and avoid callback hell by creating a fairly clean chain of then method calls. We have seen a few of these during the course. To illustrate this, you can view an artificial example of a function that fetches all notes and then deletes the first one:

All of the code we want to execute once the operation finishes is written in the callback function. If we wanted to make several asynchronous function calls in sequence, the situation would soon become painful. The asynchronous calls would have to be made in the callback. This would likely lead to complicated code and could potentially give birth to a so-called callback hell.

The --tests-by-name-pattern option can be used for running tests with a specific name:

There are a few different ways of accomplishing this, one of which is the only method. With this method we can define in the code what tests should be executed:

Both tests store the response of the request to the response variable, and unlike the previous test that used the methods provided by supertest for verifying the status code and headers, this time we are inspecting the response data stored in response.body property. Our tests verify the format and content of the response data with the method strictEqual of the assert-library.

The problem here, however, is that when using a string, the value of the header must be exactly the same. For the regex we defined, it is acceptable that the header contains the string in question.

The config module that we have implemented slightly resembles the node-config package. Writing our implementation is justified since our application is simple, and also because it teaches us valuable lessons.

The convention in Node is to define the execution mode of the application with the NODE_ENV environment variable. In our current application, we only load the environment variables defined in the .env file if the application is not in production mode.

Since our application's backend is still relatively simple, we will decide to test the entire application through its REST API, so that the database is also included. This kind of testing where multiple components of the system are being tested as a group is called integration testing.

In some situations, it can be beneficial to implement some of the backend tests by mocking the database instead of using a real database. One library that could be used for this is mongodb-memory-server.

VS Code has a handy feature that allows you to see where your modules have been exported. This can be very helpful for refactoring. For example, if you decide to split a function into two separate functions, your code could break if you don't modify all the usages. This is difficult if you don't know where they are. However, you need to define your exports in a particular way for this to work. If you right-click on a variable in the location it is exported from and select "Find All References", it will show you everywhere the variable is imported. However, if you assign an object directly to module.exports, it will not work. A workaround is to assign the object you want to export to a named variable and then export the named variable. It also will not work if you destructure where you are importing; you have to import the named variable and then destructure, or just use dot notation to use the functions contained in the named variable. The nature of VS Code bleeding into how you write your code is probably not ideal, so you need to decide for yourself if the trade-off is worthwhile.

There is no strict directory structure or file naming convention that is required for Express applications. In contrast, Ruby on Rails does require a specific structure. Our current structure simply follows some of the best practices that you can come across on the internet.

The responsibility of establishing the connection to the database has been given to the app.js module. The note.js file under the models directory only defines the Mongoose schema for notes.

The index.js file only imports the actual application from the app.js file and then starts the application. The function info of the logger-module is used for the console printout telling that the application is running.

Extracting logging into its own module is a good idea in several ways. If we wanted to start writing logs to a file or send them to an external logging service like graylog or papertrail we would only have to make changes in one place.

Before we move into the topic of testing, we will modify the structure of our project to adhere to Node.js best practices. Once we make the changes to the directory structure of our project, we will end up with the following structure:

只有在后端的所有内容都经过验证并正常工作后，才是测试前端与后端是否协同工作的好时机。仅通过前端进行测试效率极低。

通过Note模型的find方法从数据库中检索对象。该方法的参数是一个表示搜索条件的对象。由于参数是一个空对象{}，我们得到了notes集合中存储的所有笔记。 搜索条件遵循Mongo搜索查询syntax。

rm -rf package-lock.json rm -rf node_modules npm cache clean --force npm install

让我们在路由之后添加以下中间件，用于捕捉向不存在的路由发出的请求。对于这些请求，中间件将返回一个 JSON 格式的错误信息。

HTTP GET 请求应该是 安全的 。 特别是，约定俗成的是，GET 和 HEAD 方法不应具有除检索以外的行动意义。这些方法应该被认为是 " 安全的 "。。 安全意味着执行的请求不能在服务器中引起任何 副作用 。我们所说的副作用是指数据库的状态不能因为请求而改变，而且响应必须只返回服务器上已经存在的数据。

如果内容属性有一个值，笔记将基于收到的数据。如前所述，在服务器上生成时间戳比在浏览器中生成时间戳更好，因为我们不能相信运行浏览器的主机有正确的时钟设置。现在，date 属性的生成是由服务器完成的。

如果删除资源是成功的，也就是说，笔记存在并且被删除了，我们用状态代码 204 无内容 来响应请求，并且在响应中不返回数据。 对于在资源不存在的情况下应该向 DELETE 请求返回什么状态码，目前还没有达成共识。实际上，唯一的两个选择是 204 和 404。为了简单起见，我们的应用在这两种情况下都会用 204 来响应。

无论如何，我们可以通过 覆盖默认的 NOT FOUND 信息 来提供一个关于发送 404 错误的原因的线索。

Representational State Transfer，又称 REST，于 2000 年在 Roy Fielding 的 论文 中提出。REST 是一种架构风格，旨在建立可扩展的网络应用。 我们不打算深入研究 Fielding 对 REST 的定义，也不打算花时间去思考什么是 RESTful 和什么不是。相反，我们将采取一个更 狭窄的观点，只关注 RESTful APIs 在网络应用中的典型理解。事实上，REST 的原始定义甚至不限于网络应用。

用 Node 内置的 http 网络服务器直接实现我们的服务器代码是可行的。然而，这很麻烦，特别是一旦应用的规模扩大。 许多库已经被开发出来，通过提供一个更讨人喜欢的接口来与内置的 http 模块一起工作，从而缓解 Node 的服务器端开发。这些库的目的是为我们通常需要建立后端服务器的一般使用情况提供一个更好的抽象。到目前为止，用于这一目的的最流行的库是 express。

我们已经使用了与React版本16.8.0一起引入的状态钩子，它为定义为函数的React组件--所谓的功能组件提供状态。16.8.0版本还引入了效果钩子这个新功能。按照官方文档的说法。

Building a static version requires a lot of typing and no thinking, but adding interactivity requires a lot of thinking and not a lot of typing.

This is a matter of preference, and you could go either way. For this example, it is a part of ProductTable because it appears inside the ProductTable’s list. However, if this header grows to be complex (e.g., if you add sorting), you can move it into its own ProductTableHeader component.

This time, we can't avoid passing the position to the Square. After all, how can the Square know where to move the dragged knight if the Square doesn't know its own position? On the other hand, it still feels wrong because the Square as an entity in our application has not changed, and if it used to be simple, why complicate it? When you face this dilemma, it's time to separate the smart and dumb components.

React is not opinionated about the state management or the data flow; you can use Flux, Redux, Rx or even Backbone nah, avoid fat models and separate your reads from writes.

I'm going to do this every time I work on another component, so that I always have something to render. In a larger app, I would use a component playground like cosmos so I'd never write the components in the dark.

Meet the drag sources and the drop targets, the primary abstraction units of React DnD. They really tie the types, the items, the side effects, and the collecting functions together with your components.

In the component's render method, we are then able to access both the data obtained from the monitor, and the function obtained from the connector:

If the backend handles the DOM events, but the components use React to describe the DOM, how does the backend know which DOM nodes to listen to? Enter the connectors. The connectors let you assign one of the predefined roles (a drag source, a drag preview, or a drop target) to the DOM nodes in your render function.

For each component that needs to track the drag and drop state, you can define a collecting function that retrieves the relevant bits of it from the monitors. React DnD then takes care of timely calling your collecting function and merging its return value into your components' props.

React DnD exposes this state to your components via a few tiny wrappers over the internal state storage called the monitors. The monitors let you update the props of your components in response to the drag and drop state changes.

You're probably going to have an enumeration of the type constants in your application, similar to how you may have an enumeration of the Redux action types.

import了三个模块，使它们可以在该文件中使用。模块React被放入变量React，模块react-dom被放入变量ReactDOM，而定义应用主要组件的模块被放入变量App。

注意，现在必须为Note组件定义key属性，而不是像以前那样为li标签定义。

然而，这是不推荐的，即使它看起来工作得很好，也会产生想不到的问题。 在这篇文章中可以阅读更多关于这个问题的内容。

我们可以通过使用数组索引作为键来使控制台中的错误信息消失。通过向map方法的回调函数传递第二个参数，可以拿到索引。 notes.map((note, i) => ...)copy 当这样调用时，i被分配为笔记所在的数组中的索引值。

React使用数组中对象的键属性来决定如何在组件重新渲染时更新该组件生成的视图。关于这一点，更多的可以查看React文档。

创建片段的说明可以查看这里。 有用的、现成的片段也可以在市场中作为VS Code插件找到。 最重要的片段是用于console.log()命令的片段，例如，clog。这可以这样创建。 { "console.log": { "prefix": "clog", "body": [ "console.log('$1')", ], "description": "Log output to console" } }copy 使用console.log()来调试你的代码非常普遍，因此Visual Studio Code内置了这个片段。要使用它，请输入log并点击tab来自动完成。更多功能的console.log()片段扩展可以在市场中找到。

相反，当你把对象作为不同的参数用逗号隔开传递给console.log，就像我们上面的第二个例子，对象的内容被打印到开发者控制台，成为可检查的字符串。

当某些东西不工作时，不要只是猜测什么是错的。相反，要记录或使用一些其他的调试方法。

在所介绍的两种定义事件处理程序的方式中，选择哪一种主要是口味问题。

返回的函数可以被利用来定义可以用参数定制的通用功能。创建事件处理程序的hello函数可以被认为是一个工厂，它产生了定制的事件处理程序，旨在向用户问好。

Dev tools按照定义的顺序显示钩子的状态。

记录到控制台决不是调试我们的应用的唯一方法。您可以在Chrome开发者控制台的调试器中暂停应用代码的执行，方法是在代码的任何地方写下debugger命令。 一旦执行到debugger命令被执行的地方，执行将暂停。

NB 当你使用console.log进行调试时，不要用加号运算符以类似Java的方式组合objects。不是写： console.log('props value is ' + props)copy 而是用逗号把你想记录到控制台的东西分开。 console.log('props value is', props)copy 如果你使用类似Java的方式将一个字符串与一个对象连接起来，你最终会得到一个相当不可靠的日志信息。

在本课程中，我们使用state hook来为我们的React组件添加状态，这是React较新版本的一部分，从16.8.0起就可以使用。在增加钩子之前，没有办法向功能组件添加状态。需要状态的组件必须被定义为class组件，使用JavaScript的类语法。 在这个课程中，我们做了一个略显激进的决定，从第一天开始就完全使用钩子，以确保我们学习React的当前和未来风格。即使功能组件是React的未来，学习类的语法仍然很重要，因为有数十亿行的React遗留代码，你有一天可能会维护它们。这同样适用于你在互联网上偶然发现的React的文档和例子。

存储在allClicks中的那块状态现在被设置为一个数组，它包含了之前状态数组的所有项目和字母L。将新的项目添加到数组中是通过concat方法完成的，该方法并不改变现有的数组，而是返回一个数组的新副本，并将项目添加到其中。 如前所述，在JavaScript中也可以用push方法向数组中添加项。如果我们通过把项目推送到allClicks数组中，然后更新状态来添加项目，这个应用看起来仍然可以工作。 const handleLeftClick = () => { allClicks.push('L') setAll(allClicks) setLeft(left + 1) }copy 然而，不要样做。如前所述，像allClicks这样的React组件的状态是不能直接改变的。即使改变状态在某些情况下看起来是有效的，它也会导致很难调试的问题。

This article assumes that the server is started using the default configuration and that no server ports are changed.

for the exit,

got me running

existential

the @ConditionalOnProperty enables bean registration only if an environment property is present and has a specific value.

However, developing a clear understanding of each of these concepts and their role in organizing code is critical to mastering the art of programming.

The process by which the former leads to the latter may be complex, but we can apply that process using only a simple expression because that complexity is tucked away within a function.

“Starters”.

embedded servlet containers

non-functional features

You can use Spring Boot to create Java applications that can be started by using java -jar or more traditional war deployments. We also provide a command line tool that runs “spring scripts”.