Update Conditions API #267

piotr-roslaniec · 2023-08-21T11:40:58Z

Type of PR:

Feature

Required reviews:

3

What this does:

Replaces Joi with Zod, for condition validation
Adds conditionType discriminating field to conditions
Exposes conditions interface, *Props

Issues fixed/closed:

Why it's needed:

Improves developer experience for TS users
Improves type-safety

Notes for reviewers:

Downstream change addressed in Add condition_type to condition schemas nucypher#3201
Marking this as a breaking change because of breaking changes in conditions API
Slightly changed the module structure - Condition is now at .conditions.Condition instead of .conditions.base.Condition
See how condition constructors are beings used now in conditions/base/*.test.ts
See how the type-hints work now in the screenshot below

piotr-roslaniec · 2023-08-22T08:40:18Z

test/unit/conditions/condition-expr.test.ts

@@ -211,50 +212,6 @@ describe('condition set', () => {
      }
    );

-    it.each([


Removed this test because we no longer duck-type conditions and rely on conditionType instead

Perhaps you can repurpose to test to check what happens when the condition_type is either not defined, or defined but the JSON does not match what's expected based on the type.

piotr-roslaniec · 2023-08-22T08:49:04Z

test/integration/enrico.test.ts

-    const ownsBufficornNFT = ERC721Ownership.fromObj({
+    const ownsBufficornNFT = new ERC721Ownership({


Condition constructors are now taking objects

This is great 🙌

piotr-roslaniec · 2023-08-22T08:49:37Z

src/utils.ts

-export const bytesEquals = (first: Uint8Array, second: Uint8Array): boolean =>
-  first.length === second.length &&
-  first.every((value, index) => value === second[index]);
-


Unused method

piotr-roslaniec · 2023-08-22T08:50:00Z

src/index.ts

@@ -24,7 +24,6 @@ export { PolicyMessageKit } from './kits/message';
 // Conditions
 import type { CustomContextParam } from './conditions';
 import * as conditions from './conditions';
-// TODO: Not sure how to re-export this type from the conditions module


piotr-roslaniec · 2023-08-22T09:50:58Z

src/conditions/base/contract.ts

+// TODO: Consider replacing with `z.unknown`:
+//    Since Solidity types are tied to Solidity version, we may not be able to accurately represent them in Zod.
+//    Alternatively, find a TS Solidity type lib.


Potentially use this?

https://abitype.dev/api/zod

Actually I think you could probably replace pretty much anything having to do with interfacing with contracts with this maybe?

Yes, it's likely. I've already started looking into viem: #271

piotr-roslaniec · 2023-08-22T09:51:08Z

src/conditions/base/contract.ts

+  .object({
+    name: z.string(),
+    type: z.enum(EthBaseTypes),
+    internalType: z.enum(EthBaseTypes), // TODO: Do we need to validate this?


All this contract validation seems a little bit tricky, and I think there is a low probability of having a bad ABI contract. I would leave this as is.

yeah, it seems likely that ethers or viem could produce a useful error for the user if the abi isn't valid.

piotr-roslaniec · 2023-08-22T10:02:06Z

src/conditions/condition-expr.ts

+  private static conditionFromObject(obj: ConditionProps): Condition {
+    switch (obj.conditionType) {
+      case 'rpc':
+        return new RpcCondition(obj as RpcConditionProps);
+      case 'time':
+        return new TimeCondition(obj as TimeConditionProps);
+      case 'contract':
+        return new ContractCondition(obj as ContractConditionProps);
+      case 'compound':
+        return new CompoundCondition(obj as CompoundConditionProps);
+      default:
+        throw new Error(`Invalid conditionType: ${obj.conditionType}`);
+    }
+  }


RFC: Do we really need access to concrete types now that we have the conditionType in every Condition? For example, what is there to gain for our users from having an RpcCondition instead of a Condition instance?

that's a good point. I like the simplicity of just having a condition instance.

I'm also +1 for having this simplified

So just to reiterate: "I, as a TS developer, don't need to know the concrete type of my condition because I already know it's conditionType". Does that make sense?

So just to reiterate: "I, as a TS developer, don't need to know the concrete type of my condition because I already know it's conditionType". Does that make sense?

Not sure I follow. What would be the outcome of such a plan?

Let me rephrase that:

I just deserialized a condition. I want to know what type of condition it is. I can just check (by hand or programmatically) what is the value of conditionType. That's all good, the problem is solved.

But now, why would I need to know the concrete TypeScript type of my conditions? And if I ever need to know that, I follow steps in 1) and cast my condition to the desired type, condition as RpcCondition (or any other condition, based on conditionType). So, essentially what the code above is doing.

Move to Condition.fromObj

piotr-roslaniec · 2023-08-22T11:05:35Z

Hi @ghardin1314, you may be interested in reviewing this PR.

piotr-roslaniec · 2023-08-23T12:29:56Z

Wishing I used valibot instead. Perhaps in a different life.

manumonti

This is a great job 👏. In really like this approach.

manumonti · 2023-08-28T10:00:34Z

test/integration/enrico.test.ts

-    const ownsBufficornNFT = ERC721Ownership.fromObj({
+    const ownsBufficornNFT = new ERC721Ownership({


This is great 🙌

manumonti · 2023-08-28T10:47:45Z

src/utils.ts

-export const bytesEquals = (first: Uint8Array, second: Uint8Array): boolean =>
-  first.length === second.length &&
-  first.every((value, index) => value === second[index]);
-


manumonti · 2023-08-28T11:05:16Z

src/conditions/base/contract.ts

+  .object({
+    name: z.string(),
+    type: z.enum(EthBaseTypes),
+    internalType: z.enum(EthBaseTypes), // TODO: Do we need to validate this?


All this contract validation seems a little bit tricky, and I think there is a low probability of having a bad ABI contract. I would leave this as is.

manumonti · 2023-08-28T11:19:27Z

src/conditions/condition-expr.ts

+  private static conditionFromObject(obj: ConditionProps): Condition {
+    switch (obj.conditionType) {
+      case 'rpc':
+        return new RpcCondition(obj as RpcConditionProps);
+      case 'time':
+        return new TimeCondition(obj as TimeConditionProps);
+      case 'contract':
+        return new ContractCondition(obj as ContractConditionProps);
+      case 'compound':
+        return new CompoundCondition(obj as CompoundConditionProps);
+      default:
+        throw new Error(`Invalid conditionType: ${obj.conditionType}`);
+    }
+  }


that's a good point. I like the simplicity of just having a condition instance.

src/conditions/base/rpc.ts

src/conditions/compound-condition.ts

derekpierre · 2023-08-29T19:08:24Z

src/conditions/condition-expr.ts

+  private static conditionFromObject(obj: ConditionProps): Condition {
+    switch (obj.conditionType) {
+      case 'rpc':
+        return new RpcCondition(obj as RpcConditionProps);
+      case 'time':
+        return new TimeCondition(obj as TimeConditionProps);
+      case 'contract':
+        return new ContractCondition(obj as ContractConditionProps);
+      case 'compound':
+        return new CompoundCondition(obj as CompoundConditionProps);
+      default:
+        throw new Error(`Invalid conditionType: ${obj.conditionType}`);
+    }
+  }


So just to reiterate: "I, as a TS developer, don't need to know the concrete type of my condition because I already know it's conditionType". Does that make sense?

Not sure I follow. What would be the outcome of such a plan?

test/unit/conditions/base/condition.test.ts

derekpierre · 2023-08-29T19:21:34Z

test/unit/conditions/condition-expr.test.ts

@@ -211,50 +212,6 @@ describe('condition set', () => {
      }
    );

-    it.each([


Perhaps you can repurpose to test to check what happens when the condition_type is either not defined, or defined but the JSON does not match what's expected based on the type.

src/conditions/condition.ts

codecov-commenter · 2023-08-30T16:43:16Z

Codecov Report

Merging #267 (84c8ef4) into alpha (a78bc93) will increase coverage by 0.36%.
The diff coverage is 96.96%.

@@            Coverage Diff             @@
##            alpha     #267      +/-   ##
==========================================
+ Coverage   80.63%   80.99%   +0.36%     
==========================================
  Files          36       36              
  Lines        1012     1021       +9     
  Branches      112      110       -2     
==========================================
+ Hits          816      827      +11     
+ Misses        188      186       -2     
  Partials        8        8

Files Changed	Coverage Δ
src/conditions/context/context.ts	`94.73% <ø> (ø)`
src/utils.ts	`90.90% <ø> (-2.71%)`	⬇️
src/conditions/zod.ts	`83.33% <83.33%> (ø)`
src/conditions/base/contract.ts	`95.45% <95.00%> (+16.14%)`	⬆️
src/conditions/condition.ts	`97.36% <97.36%> (ø)`
src/agents/contracts.ts	`47.05% <100.00%> (ø)`
src/conditions/base/index.ts	`100.00% <100.00%> (ø)`
src/conditions/base/rpc.ts	`100.00% <100.00%> (ø)`
src/conditions/base/shared.ts	`100.00% <100.00%> (ø)`
src/conditions/base/time.ts	`100.00% <100.00%> (ø)`
... and 8 more

derekpierre · 2023-08-31T16:33:10Z

src/types.ts

@@ -8,3 +8,10 @@ export enum ChainId {
  GOERLI = 5,
  MAINNET = 1,
 }
+
+export const SUPPORTED_CHAIN_IDS = [


Is SUPORTED_CHAIN_IDS used outstide of conditions? If so, it could be good to put it back in const.

Same question for ChainId.

Moved SUPORTED_CHAIN_IDS to const.ts and ChainId to web3.ts

derekpierre · 2023-08-31T16:36:39Z

src/zod.ts

@@ -0,0 +1,31 @@
+import { Primitive, z, ZodLiteral } from 'zod';


Nice. Should we move this to the conditions directory? Unless Zod is used/will be used somewhere else?

derekpierre · 2023-08-31T16:43:59Z

test/unit/conditions/condition-expr.test.ts

+          });
+        }).toThrow(`Invalid conditionType: ${invalidConditionType}`);
+      }
+    );


Assuming not already tested somewhere else, perhaps you can also test providing a legit condition type, but the values provided don't match that type - is that possible?

For example, specify a time condition type, but provide valid contract condition values.

derekpierre · 2023-08-31T16:45:15Z

src/conditions/base/index.ts

+  }
+}
+
+export {


Do the individual base schamas and props need to be exported, or is the specific condition classes (above) sufficient.

I think props yes (because they make typing a bit easier), schemas - not so much (no direct value-add for users).

derekpierre · 2023-08-31T16:46:29Z

src/conditions/condition.ts

+    public readonly schema: ConditionSchema,
+    public readonly value: ConditionProps
+  ) {
+    const { data, error } = Condition.validate(schema, value);


derekpierre · 2023-08-31T16:47:39Z

src/conditions/condition.ts

+  public static validate(
+    schema: ConditionSchema,
+    value: ConditionProps,
+    override: Partial<ConditionProps> = {}


Do we need the override? I assumed (perhaps mistakenly so) that this would match the constructor.

Hmmm I don't think we need those anymore

src/conditions/base/index.ts

github-actions · 2023-09-04T10:47:08Z

Bundled size for the package is listed below:

build/main/src/characters: 74.22 KB
build/main/src/kits: 19.53 KB
build/main/src/conditions/context: 42.97 KB
build/main/src/conditions/predefined: 19.53 KB
build/main/src/conditions/base: 54.69 KB
build/main/src/conditions: 175.78 KB
build/main/src/agents: 39.06 KB
build/main/src/sdk/strategy: 35.16 KB
build/main/src/sdk: 46.88 KB
build/main/src/policies: 19.53 KB
build/main/src: 453.13 KB
build/main/types/ethers-contracts/factories: 82.03 KB
build/main/types/ethers-contracts: 152.34 KB
build/main/types: 156.25 KB
build/main: 667.97 KB
build/module/src/characters: 78.13 KB
build/module/src/kits: 19.53 KB
build/module/src/conditions/context: 42.97 KB
build/module/src/conditions/predefined: 19.53 KB
build/module/src/conditions/base: 54.69 KB
build/module/src/conditions: 175.78 KB
build/module/src/agents: 39.06 KB
build/module/src/sdk/strategy: 31.25 KB
build/module/src/sdk: 42.97 KB
build/module/src/policies: 19.53 KB
build/module/src: 449.22 KB
build/module/types/ethers-contracts/factories: 82.03 KB
build/module/types/ethers-contracts: 152.34 KB
build/module/types: 156.25 KB
build/module: 664.06 KB
build: 1.30 MB

arjunhassard

Nice work @piotr-roslaniec
Thank you @ghardin1314 for the DX improvements

arjunhassard · 2023-09-05T14:44:03Z

test/unit/conditions/compound-condition.test.ts

+    expect(result.error).toBeUndefined();
+    expect(result.data).toEqual({
+      ...conditionObj,
+      conditionType: 'compound',


For the documentation and Conditions Schema, should we consider compound to be a fourth condition type, or on a different 'level' from contract, rpc and time? And does the constructor tell the developer that they're creating a compound condition set?

I think CompoundCondition is somewhat different since (by definition) it can't be used on its own. That's why I didn't put it into conditions/base which is supposed to contain some basic building blocks for conditions.

Yes, the constructor expects CompoundConditionProps and provides type hints for TS developers.

piotr-roslaniec force-pushed the conditions-api branch 4 times, most recently from 758e94d to d9718ed Compare August 22, 2023 08:59

nucypher deleted a comment from github-actions bot Aug 22, 2023

piotr-roslaniec force-pushed the conditions-api branch from d9718ed to 8a8a67e Compare August 22, 2023 09:49

piotr-roslaniec commented Aug 22, 2023

View reviewed changes

piotr-roslaniec marked this pull request as ready for review August 22, 2023 10:03

piotr-roslaniec requested review from jMyles, KPrasch, cygnusv, derekpierre, manumonti and theref August 22, 2023 10:04

piotr-roslaniec force-pushed the conditions-api branch from 8a8a67e to e5b0976 Compare August 22, 2023 10:26

nucypher deleted a comment from github-actions bot Aug 22, 2023

piotr-roslaniec added the do not merge Open for review but do not merge please label Aug 22, 2023

piotr-roslaniec mentioned this pull request Aug 23, 2023

Add condition_type to condition schemas nucypher/nucypher#3201

Merged

manumonti approved these changes Aug 28, 2023

View reviewed changes

theref approved these changes Aug 28, 2023

View reviewed changes

derekpierre reviewed Aug 29, 2023

View reviewed changes

piotr-roslaniec force-pushed the conditions-api branch from fcc83eb to 19d2a9e Compare August 30, 2023 18:54

nucypher deleted a comment from github-actions bot Aug 30, 2023

piotr-roslaniec requested a review from derekpierre August 31, 2023 15:05

derekpierre reviewed Aug 31, 2023

View reviewed changes

derekpierre reviewed Sep 1, 2023

View reviewed changes

src/conditions/base/index.ts Show resolved Hide resolved

piotr-roslaniec force-pushed the conditions-api branch 2 times, most recently from f0b0b56 to 8ec9151 Compare September 4, 2023 10:45

nucypher deleted a comment from github-actions bot Sep 4, 2023

piotr-roslaniec force-pushed the conditions-api branch from 8ec9151 to b0b478f Compare September 4, 2023 11:18

arjunhassard approved these changes Sep 5, 2023

View reviewed changes

piotr-roslaniec added 2 commits September 5, 2023 20:34

feat!: add typed conditions api

86a785c

apply pr suggestions

8eaf2a7

piotr-roslaniec force-pushed the conditions-api branch from b0b478f to a4c2b44 Compare September 5, 2023 18:37

update after rebase

84c8ef4

piotr-roslaniec force-pushed the conditions-api branch from a4c2b44 to 84c8ef4 Compare September 5, 2023 18:41

piotr-roslaniec merged commit 67e43cd into alpha Sep 5, 2023
12 checks passed

piotr-roslaniec deleted the conditions-api branch September 5, 2023 18:44

piotr-roslaniec mentioned this pull request Sep 5, 2023

Enhancements to Conditions API #258

Closed

This was referenced Sep 6, 2023

Separate condition deserialization from base Condition via ConditionFactory #292

Merged

Since its a ts project, consider using Zod instead of joi? #94

Closed

derekpierre mentioned this pull request Sep 20, 2023

Consider narrowing the strings allowed for condition records in ConditionExpressionJSON #230

Closed

		const ownsBufficornNFT = ERC721Ownership.fromObj({
		const ownsBufficornNFT = new ERC721Ownership({

		@@ -0,0 +1,31 @@
		import { Primitive, z, ZodLiteral } from 'zod';

Update Conditions API #267

Update Conditions API #267

Conversation

piotr-roslaniec commented Aug 21, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-roslaniec Aug 30, 2023 • edited Loading

Choose a reason for hiding this comment

piotr-roslaniec commented Aug 22, 2023

piotr-roslaniec commented Aug 23, 2023

manumonti left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-commenter commented Aug 30, 2023 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-roslaniec Aug 31, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Sep 4, 2023

arjunhassard left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-roslaniec commented Aug 21, 2023 •

edited

Loading

piotr-roslaniec Aug 30, 2023 •

edited

Loading

codecov-commenter commented Aug 30, 2023 •

edited

Loading

piotr-roslaniec Aug 31, 2023 •

edited

Loading