The PR

[hacdias]

Track on #669.

[lidel]

I did run build, but src/windows/webui/app/ was already in place AND empty because preload nodes not longer support get and failed silently. I fixed that in 9e425ea but still no success, same error.

@olizilla does it work for you if you run npm run clean:webui before npm run build ?

@hacdias question: why do we re-compile ipfs-webui using babel?

$ babel src --out-dir out --copy-files

[BABEL] Note: The code generator has deoptimised the styling of /home/lidel/project/ipfs-desktop/src/windows/webui/app/static/js/1.da04d039.chunk.js as it exceeds the max of 500KB
[BABEL] Note: The code generator has deoptimised the styling of /home/lidel/project/ipfs-desktop/src/windows/webui/app/static/js/main.03020418.js as it exceeds the max of 500KB.

AFAIK it is already minified and chunked. It feels like a bug, but perhaps I missing something?

[lidel]

@hacdias that fixed the "white screen" issue I had, thanks! Web UI looks good now. 👍

While I was looking at that, noticed something else:

ipfs-css icons are in git 🤔

I see we are using icons from ipfs-css but we have a build step build:icons that converts them to .js files and those >100 files are committed to the repo, artificially ballooning the changeset.

We run that conversion step every time npm run build is executed, so I don't think we should be tracking those .js files. It is enough to have ipfs-css version in package.json.

I think before this PR is merged:

1. Create a commit that removes generated src/icons/*.js from git
2. Update build:icons step to use different directory for generated icons, eg. src/icons/ipfs-css and add that directory to .gitignore so they won't be tracked by git.

Does that sounds good, or am I missing something?

[olizilla]

This is copied from web UI. I'm not super fussed about the number of files in the repo if it improves the device experience ("import the icon and you're done") and files that nothing imports don't get included in the bundler (that is important to me)

That said, if you feel strongly, I could be pursuaded that it's not much effort to convert the svgs only on a case by case basis, so we end up with just the set we are using currently. This adds a little device friction to adding a new one, but not much.

Also of note, create-react-app v2 was looking at supporting this sort of conversion in we pack config so it may be something to review more generally.

[olizilla]

The vertical alignment, wrapping, and spacing in the menu items needs some love...

[olizilla]

THIS IS RAD. I like how clear it is, I found the code easy to follow. I've no major worries about merging this to master.

Things to do before merging to master:

• icons - as @lidel says it's odd to create the icons as part of the build process and store them in the repo. The general rule is don't store generated artefacts in your version control. Let's move them out of the repo and add them to the gitignore.

• README needs updating / simplifying

• make a branch v0.5 for the current app

I've left some comments in-line for specific things that we should tackle after the merge (and with tests in place!)

Things for after the merge.

• Tests! We have find a nice way to write tests for this now, or we'll never write any and we won't end up with a reliable app.

• Storybook! Can we set up a way to view the menubar app in a browser via a storybook? The electron apis are called from the redux bundle, which is neat, so we should be able to demo the presentational component outside of the app, which'd be great.

• i18n! Can we use i18next or is there a more electron friendly way of doing it?

[hacdias]

@olizilla I created a branch for v0.5 although I don't find much use for it since we have always used tags.