feature - add the NetworkId to the Job struct

[mattxyzeth]

I'm only interested in Solana jobs, but there is no way of filtering out the other jobs from the exported array without manually maintaining a set of IDs. In fetchers, I see the NetworkId and can filter that array. Thoughts on adding it to the Job struct as well? It might take a bit of elbow grease to update all the existing plugins, but I'm happy to open a PR if you'll consider it.

https://github.com/sonarwatch/portfolio/blob/main/packages/plugins/src/Fetcher.ts#L26

https://github.com/sonarwatch/portfolio/blob/main/packages/plugins/src/Job.ts#L5

[olivbau]

First of all, thank you for your feedback.

Some jobs are related to multiple networks (such as jobs on EVMs, which cover Eth, Polygon, Avalanche, etc.). Therefore, it would be necessary to create a network table, but maintaining the table manually is not desirable.

The other solution would be to modify the jobs so that they are linked to only one network. However, I believe this would require too much work at the moment.

But this is something we have taken into account for the next major update.

[mattxyzeth]

Thanks for the reply and the hard work put into this repo!

What if the networkId property was an array of NetworkId's for jobs?

[BitWonka]

hey @mattxyzeth, i ran into a similar issue, got tired of maintaining a list and made a "hacky" way to retrieve the jobs. basically checks if solana is mentioned in the executor or id. seems to have worked fine thus far

    const solanaJobs = jobs
      .filter(job =>
        (`${job.executor.toString()}-${job.id}`)
          .toLowerCase()
          .includes(NetworkId.solana),
      )

but yeah ideally the networkId/s on job would be really nice to have

[mattxyzeth]

@BitWonka looks like a simpler solution than what I came up with. I'll give it a shot. Thanks!

[mattxyzeth]

I still think you should consider adding a property so devs can avoid hacky solutions. Was this closed as something that will not be considered?