kantord/just-dashboard

Unable to run locally - hard to understand why

zawsx opened this issue · 5 comments

zawsx commented

Hi! Thanks for doing this, it looks excellent!
Sorry if this is not really an issue - I couldn't figure the code out and hope it might help other idiots like me :)

I downloaded and installed it, then
npm i -s
Is there another step I need to take? I see the travis setup which I presume is for CI

Ran
npm run dev
Had to modify node_modules\webpack-cli\bin\webpack.js to
statsPresetToOptions = require("../../webpack/lib/Stats.js").presetToOptions;

Got to this point:
justd

Can't figure out what to do next. Looked at the docs but they seem to be GHpages for https://kantord.github.io/just-dashboard/ ?

Basic problem is that I don't understand how the back end is arranged or what the front end code that calls the back end looks like? Looks as if jq-web is used to parse the yaml file? Couldn't figure out the route from api endpoint to the parser. Wanted to try everything locally.

manual_test.html for example, contains this:

<script src="dashboard.js"></script> <script src="jq.bundle.js"></script> <script src="manual_test.js"></script>

Can't figure out what to put in manual_test.js

Maybe be really helpful if there was a version of manual_test.js (say, demo.js) in dist so that,say, demo,html would run locally?

Once again, sorry for being an idiot.

kantord commented

One reason for the confusion is that there is no backend here. This is just a frontend library basically.
The backend used at https://bottoml.in/e/:user/:id is GitHub Gists. Here's the repo for that: https://github.com/kantord/bottoml.in-e/blob/master/src/index.js This basically integrates just-dashboard with GitHub Gists.

Of course, you can use your own backend. You can take the code at bottoml.in/e/ and change it so that it integrates your backend with the frontend.

jq-web is only used for executing queries. (For example, transforming a single CSV file to one chart for each line, instead of one chart for the whole file)

To run manual_test.html locally you can just npm run manual-test. That will start a dev server. You'll need to open 'manual_test.html' through that server.

Another option to use just-dashboard locally is using an Electron wrapper. I'm working on one, which can also open local files. Here's the repo: https://github.com/kantord/just-dashboard-desktop That way you don't need a web server at all.

If you want more examples, you can also consult this repo: https://github.com/kantord/ledger-cli-dashboard This one uses just-dashboard-desktop.

kantord commented

@zawsx Do you still need help? :-)

zawsx commented

That's very nice of you - I was too embarrassed to reply because the problems are because I don't understand as much of the code as you, not being able to write it so well. I respect the contributions you've made and don't want you wasting time on a newbie. I got the system to work eventually (not easy!) but I noticed one or two aspects that it might help to mention.

  1. The bundle.js (as used for one of your simple pie chart examples for instance) is 907kb ([http://bottoml.in/e/kantord/2973bdd4ad689642562018bb4091ffbd]) . Doesn't that make the idea a bit restricted in the width of uses? I had hoped to use it in a sort of 'i-frame' manner (without the iframe of course) as I think you intend.
    However, in a text and graphics-heavy page, adding 1Kb to that page weight for a graph makes it noticeably slow to load when I try it - will people for the graphs to load whilst browsing the page, especially on mobile? Obviously caching will alleviate massively but for me, it'll only be one page per website so that doesn't help.

  2. I'm actually getting bundle.js split into two parts as my webpack output, 625kb and 2548Kb. Looking back at the dashboard include, my dashboard.js is 3781kb and my vendors bundle 3335Kb
    Is there a minimisation option I can take as I can't figure out why my bundle is 2171kb, more than double yours.

I know it's a huge ask, but, as D3 has become 'serverless' (in that you can address specific 'microlibrary' functions and not have it as a black box that does everything, would it be practical to parse the yaml into more primitive calls? D3.v5.min.js is 231kb. Don't know if there is a service that can call package up the parsing and D3 functions and make them callable via some sort of API - a form of lazy loading that might avoid the loading delay?

  1. It seemed that the 'e' in
    http://bottoml.in/e/ was hardwired so I thought to split it out (making it 'g' for gist' etc) as I have no bottomlin**e** to complete :)

  2. Similarly, I wanted to have a collection of relatede files in one single gist so thought to look at the code to see how locked into the appended gist URL format you were. It seemed that you detected input file format initially by file extension so I guess the files need to end in .yml or .json etc? Wanted to group similar graphs in the same gist but that means a location.hash added to the url so a new regexp needed? For instance, I made this gist

https://gist.github.com/zawsx/84c95865d0613ce210a148421815e966

If contains two of your example files,
https://gist.github.com/zawsx/84c95865d0613ce210a148421815e966#file-g22nutri-json
and
https://gist.github.com/zawsx/84c95865d0613ce210a148421815e966#file-t22-yml

Explicit support for hashes might also bring the possibility of adding #myswitch (e.g. #local, #remote, #debug) so as to maybe bring more flexibility to the segment count approach? My localhost test of the bottomline server wouldn't resolve to the pattern I was expecting - localhost:8080/reponame by default, I got confused as localhost:8080/example worked but not localhost:8080/reponame/example

  1. Wasn't sure if the filename 'must' be called dashboard, as in dashboard.yml? I wanted to have pairs in the gist collection of files, t22-yml, t33.yml, t33A.json t33B.json etc

These next three are about about Windows being non-standard - I have the full WSL installed which doesn't suffer the issues of course so it really isn't a big deal but I still like Windows for a range of stuff as I guess many do.

  1. Had to remove the single quotes around './src/index.js' in package.json for it to work under windows - here's them removed:
    "manual-test": "webpack-dev-server ./src/index.js --hot --inline --output-filename 'bundle.js'"

  2. env variable assignments in package.json scripts don't work out of the box in W10 on mine. WEBPACK_ENV for instance.

  3. The Makefile won't work under windows as make isn't native so the examples docs can't be compiled.

Really, I can eventually figure all this out myself and see no reason to bother you unless any of it is useful to you (which is why I write). Thanks again for such an elegant and impressive solution :)

kantord commented

Thanks - this is really useful.
This project is actually quite new, and I have not received a lot of feedback from people who actually tried using it.

Actually, usage should be as clear and easy as possible. By the way when I created it I wasn't thinking that a lot of people would set up their own server.

I think all of the points you are raising are fair and should be resolved.

Regarding 3): the purpose of the code at bottoml.in isn't to be a generic solution for hosting dashboards using just-dashboard, that's why the /e/ is hard wired. The /e/ is not required at all, it's just eye candy. You can safely remove that functionality from your code entirely, if you don't need it.

If you have time, can you please create a separate issue for each point/feature request that you've raised? :-)

Thanks again, this is really useful.

zawsx commented

Split this issue into several, as requested.