Conversation
| export function assertIPFSPointer(logoPtr: MetaPtr | undefined) { | ||
| if (!logoPtr) throw new Error('assertIPFSPointer: logoPtr is undefined'); | ||
| const protocol = BigNumber.from(logoPtr.protocol).toString(); | ||
| if (!['0', '1'].includes(protocol)) | ||
| throw new Error(`assertIPFSPointer: Expected protocol ID of 0 or 1, found ${protocol}`); | ||
| } |
There was a problem hiding this comment.
assertIPFSPointer was intended an IPFS-specific method to ensure that if you are calling a method within the ipfs.ts file then the provided MetaPtr object must have a protocol ID of 1. Therefore IMO it doesn't make sense to move that out of ipfs.ts and into a generic utils file. Similarly, this method should not need to be aware of Protocol ID 0 (that was just temporary to get things working)
Gotta run to a meeting now and will finish reviewing later, but this hints to me that the PR may need some refactoring to fully decouple things
There was a problem hiding this comment.
(you might already know that, which might be why this is still a draft PR)
There was a problem hiding this comment.
You would be correct. I moved it to Utils because it doesn't really have anything to do with data specific needs like the rest of the functions in this file.
There was a problem hiding this comment.
@mds1 I don't think we should hard code 1 or 0 - are we saying that for now we need to ensure it is equal to one? And if so we could possibly warrant a function that is solely used to check if the protocol number coming in, is acceptable?
There was a problem hiding this comment.
sorry @jjwoz I'm not sure I follow your question here?
There was a problem hiding this comment.
Not sure if this helps, but IMO the approach should be:
- anything specific to IPFS (e.g. asserting something has a protocol ID of 1, or caching something to the
ipfs-storage key, or taking a pointer that's known to have an ID of 1 and generating the URL) should live inipfs.ts - anything generic (e.g. taking a pointer with an unknown protocol ID and determining it's URL) should live in the new
metaPtrs.tsfile, e.g. it seems to make sense to have theptrToURImethod live here
There was a problem hiding this comment.
so the reason I moved it because it is under the data folder - which I believe is surrounding async specific information. This is the basis for why I moved things around the way that I did.
There was a problem hiding this comment.
@mds1 after standup today, I think the intent now for this PR will to be separate out by domain context (love it!) What I will probably start doing is:
- Remove the data folder
- organize by domain
- start conversation and analyze to remove ambiguous
utilsfiles
jjwoz
force-pushed
the
feature/decouple-metaptr-logic
branch
from
0f70afb to
95ed7e0
Compare
… that use the functions. rebase
jjwoz
force-pushed
the
feature/decouple-metaptr-logic
branch
from
95ed7e0 to
5b4409d
Compare
…on that returns a boolean if it is found or not and added back ternary
jjwoz
force-pushed
the
feature/decouple-metaptr-logic
branch
from
6c5d8eb to
c834a5b
Compare
4 participants
Main goals were to separate logic out of each respected domain.