feat: import cdc files

[alxflw]

This PR fixes #47

All Cadence files that were inline are now in the one of two folders:

• web/cadence/transactions/<name>.cdc
• web/cadence/scripts/<name>.cdc

cc @shubik22

[psiemens]

I think you can actually get away without using raw.macro.

I realized we already load Cadence files in the fcl-dev-wallet project, which is also a Next app. It works by adding this line in next.config.js: https://github.com/onflow/fcl-dev-wallet/blob/main/next.config.js#L23-L29

[alxflw]

I think you can actually get away without using raw.macro.

I realized we already load Cadence files in the fcl-dev-wallet project, which is also a Next app. It works by adding this line in next.config.js: https://github.com/onflow/fcl-dev-wallet/blob/main/next.config.js#L23-L29

that worked! but it seems the cdc files have to be within the nextjs project root. LMK if that impacts testability

[10thfloor]

Great!

[10thfloor]

Is there is a way to de-dupe the cadence files?

[psiemens]

Is there is a way to de-dupe the cadence files?

Unfortunately Next requires that all loaded files are in the Next project root (/web in this case). That's one reason to copy the files into /web.

I came across this experimental feature to load external Typescript files: vercel/next.js#22867

Unfortunately it only seems to work for Typescript files and not arbitrary files loaded by Webpack.

It might be possible to load files from ../cadence using a custom Webpack config. I haven't tried this, though.

Lastly, if we do eventually convert this whole project to a Next app and remove /api, then we could move /web to the root and this problem goes away. 😄

The other problem is that the web version of the Cadence files use the 0xNonFungibleToken convention whereas the source Cadence files use file paths.

You can see here that the API replaces the file paths with addresses: https://github.com/onflow/kitty-items/blob/master/api/src/services/kitty-items.ts#L108-L123

@alxflw It'd be great to have some JS code that does this in a more generic way. It could be a nice utility that we use in both the API and web app.

[alxflw]

thanks for the input y'all. I'll focus on two things:

1. experiment with loading of files below root. I'll try the webpack config approach and see if I can get something working

2. create a helper function and unify the importing style (aliases that are replaced with relative paths on load relative paths replaced with addresses)

[alxflw]

thanks for the input y'all. I'll focus on two things:

1. experiment with loading of files below root. I'll try the webpack config approach and see if I can get something working
2. create a helper function and unify the importing style (aliases that are replaced with relative paths on load relative paths replaced with addresses)

ok, I tried a few things but didn't end up with a working solution for now. details:

1. custom next.config.js: this is only allowing me to load files inside the nextjs root. we seem to be blocked by the nextjs issue referenced earlier. TS files can be loaded but arbitrary files cannot
2. adding a utility method that could be used across web and api projects: docker compose mounts the services (web, api, db, etc) on the respective paths, so a shared utility would require changes to that setup. I feel like this would add more complexity and won't provide a lot of benefits. we'd avoid some redundant code but it'll be hard to understand why and how it is working. devs might be more confused by that

thoughts?

[alxflw]

I'd love to get this to the finish line for initial release @psiemens @10thfloor. I'll resolve the conflicts but please confirm that we exhausted our options to simplify (prior comment)

[psiemens]

Looks good overall! Just a few cleanup comments.

I say let's stick with this for now and then separately investigate better tooling to handle Cadence imports.

[psiemens]

LGTM! 🚢

Congrats on first PR! 🎉

[alxflw]

@10thfloor could you update your review so I could merge?