当JavaScript文件还没有“准备好”时，从它导出东西有什么意义呢？

Question

下面是一个例子：https://middy.js.org/docs/intro/getting-started

import middy from '@middy/core'
import middleware1 from 'sample-middleware1'
import middleware2 from 'sample-middleware2'
import middleware3 from 'sample-middleware3'

const lambdaHandler = (event, context) => {
  /* your business logic */
}

export const handler = middy(lambdaHandler)

handler
  .use(middleware1())
  .use(middleware2())
  .use(middleware3())

为什么首先导出handler，然后在定义它的同一个文件中进一步配置它？

1. 是否有充分的理由使用这种模式？
2. 另外，Node是否规范了导出，我的意思是忽略导出语句所在的位置，以及当有人导入包时，Node以某种方式确保所有导出都发生在所有其他事情之后？

奇怪的是，他们在不同的例子中使用不同的模式。这是另一个：

// import core
import middy from '@middy/core' // esm Node v14+
//const middy = require('@middy/core') // commonjs Node v12+

// import some middlewares
import jsonBodyParser from '@middy/http-json-body-parser'
import httpErrorHandler from '@middy/http-error-handler'
import validator from '@middy/validator'

// This is your common handler, in no way different than what you are used to doing every day in AWS Lambda
const lambdaHandler = async (event, context) => {
 // we don't need to deserialize the body ourself as a middleware will be used to do that
 const { creditCardNumber, expiryMonth, expiryYear, cvc, nameOnCard, amount } = event.body

 // do stuff with this data
 // ...

 const response = { result: 'success', message: 'payment processed correctly'}
 return {statusCode: 200, body: JSON.stringify(response)}
}

// Notice that in the handler you only added base business logic (no deserialization,
// validation or error handler), we will add the rest with middlewares

const eventSchema = {
 type: 'object',
 properties: {
   body: {
     type: 'object',
     properties: {
       creditCardNumber: { type: 'string', minLength: 12, maxLength: 19, pattern: '\\d+' },
       expiryMonth: { type: 'integer', minimum: 1, maximum: 12 },
       expiryYear: { type: 'integer', minimum: 2017, maximum: 2027 },
       cvc: { type: 'string', minLength: 3, maxLength: 4, pattern: '\\d+' },
       nameOnCard: { type: 'string' },
       amount: { type: 'number' }
     },
     required: ['creditCardNumber'] // Insert here all required event properties
   }
 }
}

// Let's "middyfy" our handler, then we will be able to attach middlewares to it
const handler = middy()
  .use(jsonBodyParser()) // parses the request body when it's a JSON and converts it to an object
  .use(validator({eventSchema})) // validates the input
  .use(httpErrorHandler()) // handles common http errors and returns proper responses
  .handler(lambdaHandler)

Answer 1

对于给定文件中的标识符而言，export语句的出现对任何事情都没有任何影响，包括其他模块如何/何时与其交互。两者之间没有区别

export const handler = middy(lambdaHandler)

handler
  .use(middleware1())
  .use(middleware2())
  .use(middleware3())

和

const handler = middy(lambdaHandler)

handler
  .use(middleware1())
  .use(middleware2())
  .use(middleware3())

export { handler };

但第二种方法需要更多的代码(因此有些人更喜欢第一种方法)。

它有点类似于var。无论var <someVarName>在给定块中出现在哪里，引擎所关心的都是在块中声明someVarName，而不是var行的位置。类似地，对于导出，引擎所关心的只是某个东西是否被导出，而不是export关键字碰巧在哪里。

节点以某种方式确保所有导出都发生在其他所有操作之后？

是的，主要是。导入后，模块脚本将始终在任何其他模块开始运行其(顶级)代码之前运行其所有(顶级)代码。如果有的话

console.log('1');
// 5000 lines of code
export const foo = 'foo';
// 500 lines of code
console.log('2');

使用foo的任何其他模块只有在1和2都被记录之后才会这么做。

(确保所有东西在其他模块使用之前都已正确导出的唯一例外是循环依赖关系，如果一个模块导入另一个模块，则使用循环依赖项，而另一个模块导入第一个模块时，其中一个模块将不会在另一个模块开始运行顶级代码时初始化，但export关键字的位置仍然没有影响)。

Answer 2

export声明在创建JavaScript模块以将活动绑定导出到函数、对象或原始值时使用。MDN:出口动态绑定是ES模块中引入的一个概念。这意味着当导出模块更改一个值时，该更改将从导入方可见。所以

我认为它就像引用一个对象，然后编辑原始对象。在调用引用时，将反映任何更改：

const a = {foo:'foo'}

const c = a; // Imagine this is the export and import in another file

a.foo = 'bar';

console.log(c.foo) // 'bar' - the change is reflected in the import

这里的问题是，export不像结束执行的return。导出后的代码仍在运行。JSBin例子。

导出的对象可以被认为是全局的，因此如果导入脚本进一步修改对象，那么这些更改也将反映在全局对象中。

把它看作是一个辛格尔顿可能是有用的。