-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Base should be baked into countertop #154
Labels
discussion
The conversation is the point
Comments
This was referenced May 13, 2022
Merged
I don't think there's any good reason to import the |
slifty
added a commit
that referenced
this issue
Jun 18, 2022
This is a much cleaner version of the previously-javascript Payload object that lived in the @tvkitchen/base repository. There are a few functional changes: 1. We no longer have helper access methods for `data` -- it is on the end user to convert the buffer to an object or string, etc. 2. We no longer have the type checking methods, which are now obsolete thanks to TypeScript. 3. It is no longer possible to create a Payload without populating all fields (except createdAt). 4. It is no longer possible to modify a Payload after it is created. Those last two only apply to TypeScript projects of course. Issue #154
slifty
added a commit
that referenced
this issue
Jun 18, 2022
This is a much cleaner version of the previously-javascript Payload object that lived in the @tvkitchen/base repository. There are a few functional changes: 1. We no longer have helper access methods for `data` -- it is on the end user to convert the buffer to an object or string, etc. 2. We no longer have the type checking methods, which are now obsolete thanks to TypeScript. 3. It is no longer possible to create a Payload without populating all fields (except createdAt). 4. It is no longer possible to modify a Payload after it is created. Those last two only apply to TypeScript projects of course. Issue #154
slifty
added a commit
that referenced
this issue
Jun 18, 2022
This is a much cleaner version of the previously-javascript Payload object that lived in the @tvkitchen/base repository. There are a few functional changes: 1. We no longer have helper access methods for `data` -- it is on the end user to convert the buffer to an object or string, etc. 2. We no longer have the type checking methods, which are now obsolete thanks to TypeScript. 3. It is no longer possible to create a Payload without populating all fields (except createdAt). 4. It is no longer possible to modify a Payload after it is created. Those last two only apply to TypeScript projects of course. Issue #154
Merged
slifty
added a commit
that referenced
this issue
Jun 21, 2022
Avro is a data serialization system[1]. We use it when reading and writing Payloads to Kafka as part of the AvroPayload class. This uses a similar approach but instead of creating a whole new AvroPayload we just add a new `byteSerialization` and `byteDeserialization` method to the primary Payload class. As part of this change I removed the "no extra fields" requirement from they PayloadParameters schema / type guard. It's possible this is the wrong decision but I'm actually not used to type guards ensuring no extra data (it seems like it might unnecessarily break backwards compatibility in some cases), and it was causing a hurdle for me. Avro also supports string serialization which is almost certainly faster than JSON.stringify and JSON.parse. That said: that form of serialization isn't actually used anywhere at this point so I'm not going to modify it yet. Issue #154 Base should be baked into countertop [1] https://avro.apache.org/
slifty
added a commit
that referenced
this issue
Jun 21, 2022
Avro is a data serialization system[1]. We use it when reading and writing Payloads to Kafka as part of the AvroPayload class. This uses a similar approach but instead of creating a whole new AvroPayload we just add a new `byteSerialization` and `byteDeserialization` method to the primary Payload class. As part of this change I removed the "no extra fields" requirement from they PayloadParameters schema / type guard. It's possible this is the wrong decision but I'm actually not used to type guards ensuring no extra data (it seems like it might unnecessarily break backwards compatibility in some cases), and it was causing a hurdle for me. Avro also supports string serialization which is almost certainly faster than JSON.stringify and JSON.parse. That said: that form of serialization isn't actually used anywhere at this point so I'm not going to modify it yet. Issue #154 Base should be baked into countertop [1] https://avro.apache.org/
slifty
added a commit
that referenced
this issue
Jun 21, 2022
Avro is a data serialization system[1]. We use it when reading and writing Payloads to Kafka as part of the AvroPayload class. This uses a similar approach but instead of creating a whole new AvroPayload we just add a new `byteSerialization` and `byteDeserialization` method to the primary Payload class. As part of this change I removed the "no extra fields" requirement from they PayloadParameters schema / type guard. It's possible this is the wrong decision but I'm actually not used to type guards ensuring no extra data (it seems like it might unnecessarily break backwards compatibility in some cases), and it was causing a hurdle for me. Avro also supports string serialization which is almost certainly faster than JSON.stringify and JSON.parse. That said: that form of serialization isn't actually used anywhere at this point so I'm not going to modify it yet. Issue #154 Base should be baked into countertop [1] https://avro.apache.org/
slifty
added a commit
that referenced
this issue
Jun 21, 2022
Avro is a data serialization system[1]. We use it when reading and writing Payloads to Kafka as part of the AvroPayload class. This uses a similar approach but instead of creating a whole new AvroPayload we just add a new `byteSerialization` and `byteDeserialization` method to the primary Payload class. As part of this change I removed the "no extra fields" requirement from they PayloadParameters schema / type guard. It's possible this is the wrong decision but I'm actually not used to type guards ensuring no extra data (it seems like it might unnecessarily break backwards compatibility in some cases), and it was causing a hurdle for me. Avro also supports string serialization which is almost certainly faster than JSON.stringify and JSON.parse. That said: that form of serialization isn't actually used anywhere at this point so I'm not going to modify it yet. Issue #154 Base should be baked into countertop [1] https://avro.apache.org/
slifty
added a commit
that referenced
this issue
Jun 21, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
Merged
slifty
added a commit
that referenced
this issue
Jun 21, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
slifty
added a commit
that referenced
this issue
Jun 21, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
slifty
added a commit
that referenced
this issue
Jun 21, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
slifty
added a commit
that referenced
this issue
Jun 22, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
slifty
added a commit
that referenced
this issue
Jun 22, 2022
This adds the PayloadArray class, which is a special data structure which will keep an array of Payloads sorted in order of position. There is a lot of history lost in this conversion, so I recommend viewing the original commit history if you are confused.[1] I am going to include this line, however, related to the sortedArray utilities: ``` We are going to support a sorted payload array data type, and that will involve a few methods that benefit from searches that are optimized around sorted arrays. These methods do not need to be invented, but we also don't want to bring in bloated dependencies. After looking at the method-level lodash dependencies we found that the best path would be to implement our own version of sortedIndexBy. The lodash dependency represented 2,000 lines of code, whereas our implementation is under 20. ``` Issue #154 Base should be baked into countertop [1] https://github.com/tvkitchen/base/commits/main/packages/classes/src
slifty
added a commit
that referenced
this issue
Jul 22, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 22, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 22, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 22, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 24, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 25, 2023
The concept of an abstract appliance / an appliance interface had existed in the TVKitchen base class package [1]. We had already wanted to bring it into the countertop repository, but with TypeScript we also get to clean up a lot of "faked" abstract behavior which should make it much easier for developers to build their own appliances. Issue #153 Move to Typescript Issue #154 Base should be baked into countertop
slifty
added a commit
that referenced
this issue
Jul 25, 2023
There are a lot of references in CountertopStream to classes that do not yet have types; I've opted to just use "any" and disable the linter in the appropriate places rather than couple all typescript conversions into one branch. Issue #154
slifty
added a commit
that referenced
this issue
Jul 25, 2023
There are a lot of references in CountertopStream to classes that do not yet have types; I've opted to just use "any" and disable the linter in the appropriate places rather than couple all typescript conversions into one branch. Issue #154
slifty
added a commit
that referenced
this issue
Jul 25, 2023
There are a lot of references in CountertopStream to classes that do not yet have types; I've opted to just use "any" and disable the linter in the appropriate places rather than couple all typescript conversions into one branch. Issue #154
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of #153 I think it will make a lot of sense for all of the "base" and "core" functionality to get merged into
countertop
This means the flow for a developer would be to import countertop and do whatever they want to do without needing to worry about importing a bunch of random "base-error" or "base-interface" junk. Countertop will truly be the entry point not just for appliance users but for appliance developers. This will also make it easier to make sure a countertop + appliance pair is in sync in terms of what version of constants exist instead of updating a bunch of redundant dependencies.
This will mean defining a lot of the content in https://github.com/tvkitchen/base in here, and eventually archiving that repository.
The text was updated successfully, but these errors were encountered: