You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -114,7 +114,7 @@ Because JavaScript is a dynamically typed language, protobuf.js introduces the c
114
114
115
115
There are two possible types of valid messages and the encoder is able to work with both of these:
116
116
117
-
***Runtime messages** (explicit instances of message classes with default values on their prototype) always (have to) satisfy the requirements of a valid message and
117
+
***Message instances** (explicit instances of message classes with default values on their prototype) always (have to) satisfy the requirements of a valid message and
118
118
***Plain JavaScript objects** that just so happen to be composed in a way satisfying the requirements of a valid message as well.
119
119
120
120
In a nutshell, the wire format writer understands the following types:
@@ -152,7 +152,7 @@ With that in mind and again for performance reasons, each message class provides
encodes a valid message (**runtime message** or valid **plain JavaScript object**). This method does not implicitly verify the message and it's up to the user to make sure that the payload is a valid message.
155
+
encodes a **message instance** or valid **plain JavaScript object**. This method does not implicitly verify the message and it's up to the user to make sure that the payload is a valid message.
156
156
157
157
```js
158
158
var buffer =AwesomeMessage.encode(message).finish();
@@ -162,7 +162,7 @@ With that in mind and again for performance reasons, each message class provides
162
162
works like `Message.encode` but additionally prepends the length of the message as a varint.
decodes a buffer to a **runtime message**. If required fields are missing, it throws a `util.ProtocolError` with an `instance` property set to the so far decoded message. If the wire format is invalid, it throws an `Error`.
165
+
decodes a buffer to a **message instance**. If required fields are missing, it throws a `util.ProtocolError` with an `instance` property set to the so far decoded message. If the wire format is invalid, it throws an `Error`.
166
166
167
167
```js
168
168
try {
@@ -180,22 +180,22 @@ With that in mind and again for performance reasons, each message class provides
180
180
works like `Message.decode` but additionally reads the length of the message prepended as a varint.
creates a new **runtime message** from a set of properties that satisfy the requirements of a valid message. Where applicable, it is recommended to prefer `Message.create` over `Message.fromObject` because it doesn't perform possibly redundant conversion.
183
+
creates a new **message instance** from a set of properties that satisfy the requirements of a valid message. Where applicable, it is recommended to prefer `Message.create` over `Message.fromObject` because it doesn't perform possibly redundant conversion.
184
184
185
185
```js
186
186
var message =AwesomeMessage.create({ awesomeField:"AwesomeString" });
naively converts any non-valid **plain JavaScript object** to a **runtime message**. See the table above for the exact conversion operations performed.
190
+
naively converts any non-valid **plain JavaScript object** to a **message instance**. See the table above for the exact conversion operations performed.
191
191
192
192
```js
193
193
var message =AwesomeMessage.fromObject({ awesomeField:42 });
converts a **runtime message** to an arbitrary **plain JavaScript object** for interoperability with other libraries or storage. The resulting plain JavaScript object *might* still satisfy the requirements of a valid message depending on the actual conversion options specified, but most of the time it does not.
198
+
converts a **message instance** to an arbitrary **plain JavaScript object** for interoperability with other libraries or storage. The resulting plain JavaScript object *might* still satisfy the requirements of a valid message depending on the actual conversion options specified, but most of the time it does not.
199
199
200
200
```js
201
201
var object =AwesomeMessage.toObject(message, {
@@ -361,7 +361,7 @@ Detailed information on the reflection structure is available within the [API do
361
361
362
362
### Using custom classes
363
363
364
-
Runtime message classes can also be extended with custom functionality and it is also possible to register a custom constructor with a reflected message type:
364
+
Message classes can also be extended with custom functionality and it is also possible to register a custom constructor with a reflected message type:
**Note:** Dynamically generated runtime message classes cannot be typed, technically, so you must either access its fields using `message["awesomeField"]` notation or you can utilize [typings of its static counterpart](#pbts-for-typescript) for full typings support.
496
+
**Note:** Dynamically generated message classes cannot be typed, technically, so you must either access its fields using `message["awesomeField"]` notation or you can utilize [typings of its static counterpart](#pbts-for-typescript) for full typings support.
497
497
498
498
If you generated static code to `bundle.js` using the CLI and its type definitions to `bundle.d.ts` instead, then you can just do:
499
499
@@ -574,7 +574,7 @@ Translates between file formats and generates static code.
574
574
--no-comments Does not output any JSDoc comments.
575
575
576
576
--force-long Enfores the use of 'Long' for s-/u-/int64 and s-/fixed64 fields.
577
-
--force-message Enfores the use of runtime messages instead of plain objects.
577
+
--force-message Enfores the use of message instances instead of plain objects.
0 commit comments