josepot

josepot

Member Since 7 years ago

@AdaptiveConsulting , Barcelona

Experience Points
62
follower
Lessons Completed
43
follow
Lessons Completed
210
stars
Best Reply Awards
109
repos

580 contributions in the last year

Pinned
⚡ React bindings for RxJS
⚡ A reactive programming library for JavaScript
⚡ Observables and operators for RxJS
⚡ Like Reselect but with better support for shared-selectors
Activity
Jan
24
16 hours ago
Activity icon
issue

josepot issue comment paritytech/substrate-connect

josepot
josepot

improve typings of `ToExtension` & `ToApplication`

Following task #572 this PR is fixing the following:

  • Split ToApplication and ToExtension in multiple messages based on their type, so that add-chain, remove-chain, etc. can be passed different fields. The chainId field shouldn't be directly in ToApplication and ToExtension but in each individual message.

I initially thought that it would make sense to also get rid of the parachainSpec property in this PR, but things started to get a bit out of hand. So, I decided to tackle that in the next PR, as it's very much related to the effort of adding the potentialRelayChainIds property into the add-chain message.

josepot
josepot

So, with the latest changes if that ever happened the developer would only have to rename the current ToExtension type into ToExtensionChan while making it private and then add this 2 lines:

type ToExtensionGenericStop = ToExtensionHeader & {
  type: 'stopEverything'
}

export type ToExtension = ToExtensionChain | ToExtensionGenericStop

That's it. But again, if you rather me removing the internal "header" types altogether, I can do that too, for sure!

Activity icon
issue

josepot issue comment paritytech/substrate-connect

josepot
josepot

improve typings of `ToExtension` & `ToApplication`

Following task #572 this PR is fixing the following:

  • Split ToApplication and ToExtension in multiple messages based on their type, so that add-chain, remove-chain, etc. can be passed different fields. The chainId field shouldn't be directly in ToApplication and ToExtension but in each individual message.

I initially thought that it would make sense to also get rid of the parachainSpec property in this PR, but things started to get a bit out of hand. So, I decided to tackle that in the next PR, as it's very much related to the effort of adding the potentialRelayChainIds property into the add-chain message.

josepot
josepot

Yeah I understand that it's the exact same thing anyway from the point of view of the user, but I'm placing myself from the point of view of someone who adds a new message to substrate-connect-protocol in the future, and gets "blocked" because they don't know which value of chainId to provide for their new message.

I mean, if they know basic TS they wouldn't get blocked, they could simply do:

type ToExtensionChain = ToExtensionHeader &
  (
    | ToExtensionAddChain
    | ToExtensionAddWellKnownChain
    | ToExtensionRpc
    | ToExtensionRemoveChain
  )

type ToExtensionGenericStop = Pick<ToExntensionHeader, 'origin'> & {
  type: 'stopEverything'
}

export type ToExtension = ToExtensionChain | ToExtensionGenericStop

That being said, let me make a small change that perhaps could make things even easier for whenever that happens... Or if you want I can just explicitly add all the properties in all the messages, up to you. I really don't feel so strongly about this.

Activity icon
issue

josepot issue comment paritytech/substrate-connect

josepot
josepot

improve typings of `ToExtension` & `ToApplication`

Following task #572 this PR is fixing the following:

  • Split ToApplication and ToExtension in multiple messages based on their type, so that add-chain, remove-chain, etc. can be passed different fields. The chainId field shouldn't be directly in ToApplication and ToExtension but in each individual message.

I initially thought that it would make sense to also get rid of the parachainSpec property in this PR, but things started to get a bit out of hand. So, I decided to tackle that in the next PR, as it's very much related to the effort of adding the potentialRelayChainIds property into the add-chain message.

josepot
josepot

The chainId field shouldn't be directly in ToApplication and ToExtension but in each individual message.

So I guess you disagree with me, but what I meant is exactly that chainId shouldn't be ToApplicationHeader or ToExtensionHeader, but in each individual message.

There will inevitably be a day where someone adds a message that doesn't need a chainId, and instead of moving the chainId field like they should they will instead incorrectly pass a dummy value.

I don't disagree with you! Please notice that neither ToApplicationHeader nor ToExtensionHeader are being exported :slightly_smiling_face: They are just there for convenience. What's exported is:

export type ToExtension = ToExtensionHeader &
  (
    | ToExtensionAddChain
    | ToExtensionAddWellKnownChain
    | ToExtensionRpc
    | ToExtensionRemoveChain
  )

and

export type ToApplication = ToApplicationHeader &
  (ToApplicationError | ToApplicationChainReady | ToApplicationRpc)
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

improve typings of `ToExtension` & `ToApplication`

Following task #572 this PR is fixing the following:

  • Split ToApplication and ToExtension in multiple messages based on their type, so that add-chain, remove-chain, etc. can be passed different fields. The chainId field shouldn't be directly in ToApplication and ToExtension but in each individual message.

I initially thought that it would make sense to also get rid of the parachainSpec property in this PR, but things started to get a bit out of hand. So, I decided to tackle that in the next PR, as it's very much related to the effort of adding the potentialRelayChainIds property into the add-chain message.

Activity icon
created branch

josepot in paritytech/substrate-connect create branch josep-improve-typings

createdAt 1 hour ago
Jan
21
3 days ago
pull request

josepot merge to paritytech/substrate-connect

josepot
josepot

fix popup to show again the network connections

Activity icon
issue

josepot issue comment paritytech/substrate-connect

josepot
josepot

Stop sending relay chain name in the port name

We should send it in one of the messages (spec). Needs a little thought so as not to make the MessageToManager needlessly complicated.

josepot
josepot
Activity icon
issue

josepot issue paritytech/substrate-connect

josepot
josepot

Stop sending relay chain name in the port name

We should send it in one of the messages (spec). Needs a little thought so as not to make the MessageToManager needlessly complicated.

push

josepot push paritytech/substrate-connect

josepot
josepot

add remove-chain type into ToExtension (#671)

commit sha: f9865b8b787b7bc2398dac6e3c2b0d5b08608634

push time in 3 days ago
Activity icon
delete

josepot in paritytech/substrate-connect delete branch josep-add-remove-chain

deleted time in 3 days ago
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

add `remove-chain` type into `ToExtension`

Following task #572 this PR is fixing the following:

  • Add a new message "remove-chain" that tells the extension that we no longer want a chain. This is equivalent to the legacy action: "disconnect".
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

add `remove-chain` type into `ToExtension`

Following task #572 this PR is fixing the following:

  • Add a new message "remove-chain" that tells the extension that we no longer want a chain. This is equivalent to the legacy action: "disconnect".
Activity icon
created branch

josepot in paritytech/substrate-connect create branch josep-add-remove-chain

createdAt 3 days ago
push

josepot push paritytech/substrate-connect

josepot
josepot

ConnectionManager: ensure that chain gets removed if port closes too early (#670)

commit sha: 95276b634a290801543b734b0c086180ad95aa0e

push time in 3 days ago
Activity icon
delete

josepot in paritytech/substrate-connect delete branch josep-fix-race-condition

deleted time in 3 days ago
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

ConnectionManager: ensure that chain gets removed if port closes too early

I can't believe that I missed this... :grimacing:

push

josepot push paritytech/substrate-connect

josepot
josepot

Fix input parameter of connect on ExtensionMessageRouter (#669)

josepot
josepot

ConnectionManager: ensure that chain gets removed if port closes too early

commit sha: 0c933202a2a93e13b66c226866a02032bcf4c0cd

push time in 3 days ago
push

josepot push paritytech/substrate-connect

josepot
josepot

ConnectionManager: ensure that chain gets removed if port closes too early

commit sha: 42afaf2b7fb56bf8888a2f9b5d0bd1cfffdf40c2

push time in 3 days ago
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

ConnectionManager: ensure that chain gets removed if port too early

I can't believe that I missed this... :grimacing:

Activity icon
created branch

josepot in paritytech/substrate-connect create branch josep-fix-race-condition

createdAt 3 days ago
pull request

josepot merge to paritytech/substrate-connect

josepot
josepot

Fix input parameter of connect on ExtensionMessageRouter

josepot
josepot
push

josepot push paritytech/substrate-connect

josepot
josepot

add chain-ready message type (#667)

  • add add-chain-ok message type

  • add-chain-ok -> chain-ready

commit sha: 6923931a60f502a18743049b1b2a63118e3d09f4

push time in 3 days ago
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

add `chain-ready` message type

Following task #572 this PR is fixing the following:

  • When you send a message to add a chain, the extension should return two one messages that don't doesn't exist yet: one "add-chain-started" message immediately returned, and that is used to know whether the extension exists, and one "add-chain-ok" or "add-chain-error" message. All three two messages indicate which chainId they refer to, and "add-chain-error" also provides an error string.

Now that we have the add-chain-ok message, there is no reason for the ConnectionManager to try to handle RPC messages that came too early. Instead, now it should send an error to the content-script if an RPC message comes before the add-chain-ok message has been sent. Therefore, this logic and the related tests have been updated accordingly.

Regarding the code of the ExtensionProvider: I've tried to make as little changes as possible while still ensuring that the Promise returned by connect now doesn't resolve until it receives the add-chain-ok response from the Extension. I've also tried to make as little changes as possible to the tests of the ExtensionProvider b/c well... it's out of the scope of this PR to improve those tests, but IMO they should be improved at some point.

Activity icon
delete

josepot in paritytech/substrate-connect delete branch josep-chain-add-ok

deleted time in 3 days ago
Jan
20
4 days ago
push

josepot push paritytech/substrate-connect

josepot
josepot

Update node versions; 16.6.1 to 16.x; Add 17.x (#662)

josepot
josepot

replace regenerator-runtime with .babelrc (#660)

  • replace regenerator-runtime with .babelrc

  • fix merge issue

josepot
josepot

Move all devDependencies to the root package.json (#657)

  • Move all devDependencies to the root package.json

  • update @hot-loader/react-dom to 17.0.2

  • push updated yarn.lock

josepot
josepot

Update westend-connect bootnode identities (#664)

Co-authored-by: Nikos Kontakis [email protected]

josepot
josepot

Remove old Kusama bootnodes (#663)

Co-authored-by: Nikos Kontakis [email protected]

josepot
josepot

add add-chain-ok message type

commit sha: e3b34c089f8768facfd14af3b306b515624f0242

push time in 3 days ago
pull request

josepot pull request paritytech/substrate-connect

josepot
josepot

add `add-chain-ok` message type

Following task #572 this PR is fixing the following:

  • When you send a message to add a chain, the extension should return two one messages that don't doesn't exist yet: one "add-chain-started" message immediately returned, and that is used to know whether the extension exists, and one "add-chain-ok" or "add-chain-error" message. All three two messages indicate which chainId they refer to, and "add-chain-error" also provides an error string.

Now that we have the add-chain-ok message, there is no reason for the ConnectionManager to try to handle RPC messages that came too early. Instead, now it should send an error to the content-script if an RPC message comes before the add-chain-ok message has been sent. Therefore, this logic and the related tests have been updated accordingly.

Regarding the code of the ExtensionProvider: I've tried to make as little changes as possible while still ensuring that the Promise returned by connect now doesn't resolve until it receives the add-chain-ok response from the Extension. I've also tried to make as little changes as possible to the tests of the ExtensionProvider b/c well... it's out of the scope of this PR to improve those tests, but IMO they should be improved at some point.

Previous