Loading FontAwesome,or using Tulicons, from a widget

Support, Troubleshooting, & Help
1

Is there a way in my custom widget I can import fontawesome? You can’t load it from a CDN using because the widget is in a sandbox. I don’t think I’d really want to do that, anyway, it’s not good when the CDN can’t be reached for some reason. Maybe to do this right Tulip would have to host fontawesome at the same place it feeds out the apps.

Alternatively, there’s something called tulicons.woff but I’m not sure how / if I can use it. From a couple of quick experiments it, too, doesn’t seem accessible outside of the sandbox. Maybe I could reload it on my own inside the css but i’m wondering if it’d be better if Tulip somehow injected it for my use? Tulicons contains 304 glyphs and they’re actually pretty nice!

2

Hey @wz2b,

A couple approaches you can take here. I have attached a custom widget what imports any google font and you can use it throughout your app. We don’t natively support a file system for your custom widget (the normal approach to managing fonts in JS) to limit complexity for a new user.

We also limit the list of external libraries because many popular Js libraries (see react, angular, vue, etc.) require compilation before they can be run, and this can’t be easily done in the custom widget runtime. Having said that, if there are libraries that you want to use, let us know and the developers can add that library for allowed external libraries.

For the time being, you can import libraries outside of the supported list with this code:

async function loadScripts(...urls) {
  for (const thisUrl of urls) {
    console.log(`Loading script "${thisUrl}"...`);

    const response = await fetch(thisUrl);
    const responseBody = await response.text();

    const scriptElm = document.createElement("script");
    const inlineCode = document.createTextNode(responseBody);
    scriptElm.appendChild(inlineCode);
    document.body.appendChild(scriptElm);

    console.log(`Script "${thisUrl}" successfully loaded`);
  }
}

Hope this helps.
Pete
customWidget-Text Box - Any Font.json (3.3 KB)

3

That will work!

A customer ‘filesystem’ of sorts would be cool, though. Or, if not that, at least he concept of user ‘libraries’ that get pre-loaded. My smart/pretty table widget’s code is getting pretty sizeable.

4

I agree, a filesystem for a widget would be powerful - Let me run that one up the ladder and understand if this is possible.

I hadn’t thought about widget libraries for a specific customer, but thats a great idea. I will write up a feature request for that and see where it goes.

Keep the great ideas coming!
Pete

5

Maybe we’re calling this the wrong thing, though. I keep saying “filesystem” but what I really mean is a slice of the web server, so it’s more than just a place to store files. It’s also a place that’s docked somewhere on the same domain so that I can things in from the HTML without it causing all kinds of CORS/CSRF anger in the browser.

6

Are you thinking something like Tulip Player cache, which would be analogous to browser cache?

7

Not exactly. This is very rough but maybe will give you the idea what I am thinking:

image
image821×516 130 KB

with a few improvements

  • I think it’d be an either/or case … either you’d specify HTML/JS/CSS or you’d say load it from somewhere else
  • I wouldn’t just specify the .js I’d make some kind of bundle format. Maybe it’s a .zip file with an html, js, and css file inside?
  • Maybe you don’t need a ‘folder’ concept - it might just be a flat structure and you name things well.
  • Maybe eventually you can get /sharedWidgets/barCode.zip which is a widget that I really like so I’m publishing it in a place the entire Tulip community can see/use it
  • We would probably need to figure out some way to version these things.
  • Maybe it’s a dropdown menu of available widgets, to save typing

This isn’t a well-formed idea yet :slight_smile:

8

Spent a little time talking with our engineering team last week. Feels like this ask falls into 2 major buckets:

Simple - Widget assets, like images or fonts. This is way simpler to incorporate, and would resolve most of the times I have wanted a widget filesystem. Probably could be a flat file system and the concept of sharing files probably wouldn’t be necessary to be viable.

More Advanced - Multi JS files in one widget. For more complex JS, having multiple JS files is incredibly useful, but it is significantly more complicated to enable for custom widgets. Here you probably want sharing of files across widgets, maybe version control on those shared files, etc.

The difference in size of those asks will likely directly correlate to when they are implemented. I created a feature request for at least basic flat file access, and I will continue the conversation around the scope of true multi-file support.

Pete