How to refer to local js files in the html?

[brettforbes]

I have a standard html file, and a local js file ("stix_tree.js") I want to include in the body as a function.

I import it as shown below

    <script type="text/javascript" src="stix_tree.js"></script>

yet it throws an error in the console which shows the file is not found

How should one refer to local js files in the html file? I tried using a dot and slash but that didnt seem to work either. What am i doing wrong? Should there be some kind of help on these basic gotcha's?

[curran]

Thanks for reporting! Can you please share a link to the viz that is broken?

[curran]

I made a test case of importing a file the way you are doing it, and it seems to work.

https://vizhub.com/curran/f7f292e92a0942e7b0658f5d5325810f?edit=files&file=index.html&tabs=test.js%7Eindex.html

[curran]

Oh actually it broke when I put an underscore in the name! That must be a bug. Please try removing the underscore from the file name and see if it works.

[brettforbes]

hey Curran, thanks for helping.

I, I changed all of the filenames so there was no underscores, which is a gotcha for Python guys like myself.

but i still get 2 errors about import in the results webpage, yet the thing works

What am i doing wrong? Are those errors coming from the index.html imports or the index,js imports? https://vizhub.com/brettforbes/376352ffa3c149829be74cec0d053313

[curran]

I think it probably has to do with the mixing of import styles.

On the one hand, you are trying to use Vanilla JS by importing scripts with the <script> tag. That by itself should work, provided the scripts are actually vanilla JS scripts - without the ES6 imports.

On the other hand, your scripts imported in that way use the ES6 import syntax, like import { select, json, drag, event } from 'd3';, which is not compatible with Vanilla JS <script> tags.

In order to support that kind of import, the concept of index.js and bundle.js was introduced in VizHub v2, which, along with package.json allows you to author code as ES modules. If you want to leverage this way of doing it, you'll need to organize your code such that index.js is the entry point, which imports from all the other local files. That generates bundle.js, which should be the only script you pull into the index.html.

If you don't want to use that bundling feature, and truly want to use the old <script> tag way of importing scripts, then you'll need to get rid of all the ES6 imports that occur there. So, replacing import { select } from 'd3' with d3.select. However, I would not recommend this.

In any case, there's a lot going on in that example. I would suggest to start with something small and get it working, then incrementally build the complexity back up. In summary, there are 3 ways you can organize your scripts:

• Use <script> tags for each script - this is the old school way. If you do this, you need to manually order the imports so that things are defined in the right order. You also need to use global variables to talk across scripts. You also need to avoid using the import { .. } from 'd3' syntax, because that is not supported by regular HTML<script> tags. While this would probably eventually work, I would not recommend it. This is how folks did things in the early years of JavaScript, before there were modules and package managers.
• Use the "V2 Runtime" of VizHub, which is triggered when you have both an index.html and an index.js file. This mode lets you author ES6 modules using index.js as the entry point. If you do this, you can use the import {select} from 'd3' syntax to pull things in from D3, and also import { something } from './myLocalFile'; to pull in local files. In this case, Rollup is used internally to generate bundle.js from index.js and package.json. The only <script> tags that should be used with the V2 Runtime are the libraries from a CDN, e.g. D3 from UNPKG, and bundle.js. While this works fairly well, there is a newer way to do things. Here's an example that shows this setup: https://vizhub.com/curran/81606d10ab2b4b2fb39b0fc740195bfd?edit=files
• Use the VizHub V3 Runtime, which is triggered when you have an index.js file, but not an index.html file. This is the setup that support hot reloading and importing across vizzes. Hot reloading is possible here because it's expected that index.js exports a main function that serves as the overall entry point. This is the setup I would recommend in general, since it supports hot reloading, and also is compatible with major frameworks when you export the code. However, it is a bit more work to get everything working in this way. Here's an example that shows this setup of the V3 Runtime: https://vizhub.com/curran/blank-slate All the examples from this new course use this setup: https://www.youtube.com/watch?v=bZhWCO-bDek&list=PL9yYRbwpkykthTFJl9vYr_C0FCjRIn_7G

For your case, it looks like you want to leverage HTML, so perhaps the VizHub v2 runtime might be the best way to go. Good luck!

[brettforbes]

Great explanation, thanks. You have clarified things for me greatly.

I like either the v2 approach best because i can still have some named div's on the html page and i understand it reasonably well. I just need to get a group of radio buttons going as well, and respond to their changes from the index.js page. Hmm, need to work on that

I may have to create the buttons through javascript/d3, will have to research this

Yes there are a lot of pieces going on in there, and to be fair i did produce the tree view based on a single file first. sing a radio button to switch through datasets is stage 2. Stage 3 is the second svg working page.

Basically, this is just developing the two visualisations, which will later on go into a SaaS/UI framework. Just so you can make sense of it, you can imagine the whole page being something like

The middle pane will be pretty cool, it will look something like the following. I am doing that in webCola using the Bounding box example

[curran]

Wow! That looks like a pretty neat project! The pieces all seem doable.

This conversation makes me realize that VizHub needs better documentation, in a prominent place in the platform, that explains all this.

Here's a first stab at it. I'd like to put this in the site at some point:

Creating clear and comprehensive documentation is essential for helping users understand and effectively use VizHub's runtime options. Here's a structured documentation outline based on the provided raw material:

VizHub Runtime Options

Overview

VizHub offers various runtime options to cater to different development styles and requirements. Understanding these options will help you organize your scripts and leverage VizHub's features effectively.

Runtime Options

1. Vanilla JavaScript with <script> Tags

• Description: Traditional way of using JavaScript by importing scripts directly into the HTML file using <script> tags.
• Usage: Suitable for simple projects or when you want to avoid using modern JavaScript modules.
• Limitations: Requires manual ordering of scripts, use of global variables for cross-script communication, and avoidance of ES6 import syntax.
• Recommendation: Not recommended due to limitations and lack of module support. Could be useful for reviving old code as a first step towards upgrading to modern patterns.

2. VizHub V2 Runtime

• Description: Enables authoring ES6 modules using index.js as the entry point. Supports bundling with Rollup to generate bundle.js. Supports React JSX.
• Trigger: Presence of both index.html and index.js files.
• Usage: Allows the use of ES6 import syntax for importing modules and local files. Recommended for projects that need HTML structure and want to use modern JavaScript features. Also, package.json is used to signal which browser globals to use.
• Example: V2 Runtime Example

3. VizHub V3 Runtime (Hot Vizzes)

• Description: Supports hot reloading and importing across vizzes. Expects index.js to export a main function as the entry point.
• Trigger: Presence of index.js file without index.html.
• Usage: Recommended for new projects that require hot reloading and integration with major frameworks. Enables faster iteration and collaboration.
• Characteristics: Vizzes with hot reloading are indicated by a glowing frame.
• Example: V3 Runtime Example, and all examples from Constructing Visualizations 2024.

Hot Reloading

• Key Features:
  • No index.html file.
  • main function in index.js serves as the entry point.
  • Supports state management with state and setState.
• Benefits: Accelerates development and collaboration by allowing live updates without refreshing the page.
• Examples:
  • D3 Transitions with Hot Reloading
  • Interaction Patterns
  • Animation Patterns

Interactive Widgets

• Features:
  • Alt + Drag on a number to change its value.
  • Alt + Click on a color hex code to open a color picker.
  • Alt + Click on a boolean value to toggle it.
  • Alt + Click on a URL to open it in a new tab.
• Purpose: Enhance code editing experience by providing interactive ways to modify values directly in the editor. Only really works well with the V3 Runtime.

Exporting and Building

• Process:
  • Click the export icon to download a .zip file containing the project.
  • Run npm install, npm run build, and http-server to serve the project locally.
  • See also https://github.com/vizhub-core/vite-export-template for how to integrate with a Vite app and automate the export.
• Customization: After exporting, you can modify the Rollup config or switch to another bundling system like Webpack.

Conclusion

By choosing the appropriate runtime option and leveraging hot reloading and interactive widgets, you can streamline your development process and enhance collaboration in VizHub. Explore the examples provided to get a better understanding of how to implement these features in your projects.

[brettforbes]

Hey that would be so useful.

I am sure for topline JS people your setup seems sensible, yet i am more of a Python person, and the whole JS setup seems pretty weird, so your documents are lifesavers!! Thanks

I'm glad you like the viz prototypes I am building. There are some new concepts there in visual working which look great. Its also interesting how easy it is to slice and dice complex data domains by applying hierarchies to features, and having this focus on defining and attaching sub-graphs, and then finally promoting them as official records. There's some cool features for sure, and I want to build some more novel viz's in the future.

We are building an open-source, low-code, content-driven visualisation platform and are working on our first application in cyber security.

Our architect, @wildone, has proposed a method by which we will be able to develop a visualization in vizhub, and integrate it with an object to which we write to/from for events/data (e.g. mouse-click), and then publish it as a widget on our platform.

That way, others can use your platform to develop visualisations that can convert into widgets in our platform. Working together can only help everyone.

See @wildone for details, obviously I am not the right one for that.

[brettforbes]

help,.

why cant i use webCola using your version 2.0 approach? I does not seem to load properly.

Can you get it to load using import statements? Your approach does not seem to work with this library. What to do? I need to demo on Thursday https://vizhub.com/brettforbes/d1ec7715179542a39bf4bbc2ed99e4e0

[curran]

WebCola is somewhat of a unique case. For that you can try just accessing the global window.cola. The ES6 imports and references to globals both still work in the V2 runtime.

This is a good case that I'd like to support better in the future. WebCola is tricky because the CDN-hosted library does not include a browser build. For that it looks like we need to use that custom CDN URL that pulls the code from GitHub.

[brettforbes]

Following your advice, I removed the import statements and then just used this line

  var cola = window.cola.d3adaptor().size([width, height]);

and it seemed to now import the file without complaining. Of course, I still have errors in it, but it seems pretty solid.

Can you look at private vizhub files?

[curran]

Glad it works!

Can you look at private vizhub files?

Only if you add me as a collaborator on your private viz, I can view it.