Simple Flat array of all Icons?

[zagarskas]

Is there a JSON or PHP flat Array out there that just has only the icon identifiers?

Problem:
The 35MB JSON file is not the droid I am looking for

Solution:
The droid I am looking for looks like this:
{ "abacus", "address-book", "alicorn" ect... }

It does not need any taxonomy or categorization.
It does not need to be multi-dimensional.
no additional data about any icon is needed.

Just a flat list of all 3500 unique IDs
(a separate file for brands I think may be needed)

I expect it would be, oh, maybe 35-350kb? (not 35,000kb)

[tagliala]

Hi,

maintaining metadata and all variations for specific needs is hard and we had a lot of discussions about this topic

The 35MB JSON file is not the droid I am looking for

Where it this file?

I can see 876K icons.yml in FA 6.1.1 pro and 385k icons.yml in FA 6.1.1 Free

Also the json file in the free repo is 4.35 Mb

Where does the 35MB comes from?

[zagarskas]

Check this out:
https://www.screencast.com/t/ZKofLkxiVdT
I think it will clarify...

I also want to make clear here: what is in the icons.json file is impressive. As a dev who works with gMaps API and the complexities of country, state, region, zip, county, ect... I truly appreciate the beauty of the organization in icons.json

However, what I am asking for is simple. Exceedingly simple
fundamental: just a flat array of every icon, no taxo, no cats, no nesting

I also understand perhaps its not that simple to export?
I am assuming that some custom system has been built to export the icons.json file.
and I can see the nesting process there is elaborate and complex...
I see how that is useful to some, but for my purposes I have to reduce the complexity, which is complex in itself. lol.

Previously I had to go into the CSS file and parse it with some fancy php to strip it down to a flat list of all icon IDs,
thats fine... but... lol... I want my life to be easy

Ironically, it took me less time to copy and paste the IDs from the CSS file after that first stripdown in PHP
but now, its tedious.

on the off chance making my life easy is just asking a dev for a flat array,
perhaps all that takes is clicking an export button on FA's end... so, figure I would ask.

[tagliala]

Hi, apologies for the late reply

Where does the 35MB comes from?

Thanks, I've got it. It's only in the downloadable file because it is too big also for the fontawesome-pro npm package. That json file also contains svgs, so it is a copy of Font Awesome rather than pure metadata

However, what I am asking for is simple. Exceedingly simple
fundamental: just a flat array of every icon, no taxo, no cats, no nesting

Would like to clarify my previous comment

The use case is absolutely legit, as any other use case who may need just the ids with the unicode, just ids except for brands, ids separated by style (useful in FA Free, because not all regular icons are available), or a lot of other use cases we don't know about.

Then, some use cases may work better with json, others with yml formats. This will easily load to a proliferation of metadata files to configure for the build export on Font Awesome's side.

Having a single export with all the information allows us to support a larger number of use case, but the drawback is on size and developers should parse the information and optionally reduce it to the strict amount they need for the their specific use case

Previously I had to go into the CSS file and parse it with some fancy php to strip it down to a flat list of all icon IDs,

An alternative could be to parse scss/_variables.scss may help, all the icons starts with $fa-var-

I would also ask @robmadole for some thoughts on this and if there are opportunities to improve metadata management

[robmadole]

@zagarskas have you considered using our GraphQL API? https://fontawesome.com/v6/docs/apis/graphql/get-started

[zagarskas]

I have not.
Mixed feelings about that.

On one hand I am extremely impressed and happy there is a whole API - seeing so many possibilities

On the other hand... its like "yuk. I do not want to sit here for 8 hours and build a whole PHP application layer with tokens and api keys, read through the documentation, debug/test, just to get an array of icons -- and then spent 20 hours wiring that into my themes and applications -- to later deal with 2 years of rug pulls and maintenance for my maintenance and testing for my test cases to make tests for error codes when version 3.98.7.6 comes out and my keys need to be refreshed every 2 hours because the 3.5 version is deprecated finding myself tapping into the WP database to store custom transient data and cron jobs to deal with another external api -- all while 1000s of people are trolling my support accounts and email because their theme does not work anymore"

I LOVE the idea of using the API in a Select2 JSON call
I HATE the idea of having to support that

It deserves closer examination, for sure...
Mixed feelings
thank you

[darkylmnx]

@robmadole

I have this issue too because the API is only in English and there's no option to change the locale.

So parsing the JSON is the only option but it's way to big to store in memory.

[airtonix]

@zagarskas Not using php, I'm in the Typescript NextJs MasterRace Land

Here's how I solved this problem:

1. Allow importing of yaml files.

next.config.js

const withContentlayer = require("next-contentlayer").withContentlayer;

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  trailingSlash: true,

  webpack: (config) => {
    config.module.rules.push({
      test: /\.md$/,
      loader: "frontmatter-markdown-loader",
      options: { mode: ["react-component"] },
    });

    config.module.rules.push({              // 👈 
      test: /\.ya?ml$/,                     // 👈
      use: "js-yaml-loader",                // 👈
    });                                     // 👈

    return config;
  },
};

module.exports = withContentlayer(nextConfig);

2. Redefine how the yaml file is typed

fontawesome.d.ts

module "@fortawesome/fontawesome-free/metadata/icons.yml" {
  import {
    IconDefinition,
    IconName,
  } from "@fortawesome/fontawesome-common-types";

  export default {} as Record<IconName, IconDefinition>;
}

this types the normally any return type of a yaml import correctly as an object whose keys are any of the font awesome names

3. import it and use the keys

services/Cms/Collections/PropertyAttributeCollection.ts

import type { CmsCollection } from "netlify-cms-core";
import icons from "@fortawesome/fontawesome-free/metadata/icons.yml"; //1️⃣ 

import * as Fields from "../Fields";

export const PropertyAttributeCollection: CmsCollection = {
  name: "property_attributes",
  label: "Property Attributes",
  label_singular: "Property Attribute",
  folder: "content/property_attributes",
  create: true,
  slug: "{{title}}",
  summary: "[{{id}}] {{date_created | date}}:  {{title}}",
  sortable_fields: ["title", "date_created"],
  fields: [
    Fields.Identifier.IDField,
    Fields.Date.CreatedField,
    Fields.Date.UpdatedField,
    Fields.General.TitleField,
    {
      label: "Plural",
      name: "plural",
      widget: "string",
    },
    {
      label: "Icon",
      name: "icon",
      widget: "select",
      options: Object.keys(icons),           // 2️⃣ 
      hint: "Icon name from https://fontawesome.com/search?o=r&s=solid%2Cregular&f=classic",
    },
  ],
};

[zagarskas]

Hey nice work!

but... after going through all that don't you think my suggestion: asking for a "flat array" is a reasonable/useful thing to ask for?

Because, my approach here was similar, I just ended up stripping down the data into my own array and using it in a select2 via AJAX so when 20 of those fields have to display on the same page they make an AJAX request instead of load up 1000s+ icons in Regular, Thick, Thin, Duotone, ect...

For example, now try to take your code here and make it so it can switch between fa-solid, fa-regular, fa-light, fa-duotone, then try to group them into ideas like brands, icons, trucks, hospitals, recreation, cooking, interface elements, menus, arrows ect..., and then, after all that, get ready to do it all over again for V7 and V8

and then engineer all that into some WordPress, Magento and Shopify themes sold to graphic designers that use a WYSIWYG UI and pretend to be web-developers... lol. (while fielding 100s of rude emails from them on theme directories that say things lilke "I can search the icon on fontawesome.com, hows come we cant do that in your theme? HRRUUUU?" ) lol

I feel like, when that is your STACK, you might agree with my OP "hey, can we uh, like, get an array of all these?"

Because, ya. I am aware what you have demonstrated can be done. - lol -
been pullen stunts "like that" since 2015 by stripping down the system
keep in mind Font-Awesome/js-packages/@fortawesome/fontawesome-common-types/index.d.ts didnt exist till Feb 7, 2022

so every year it HURTS to do ALL OVER AGAIN when the classes change and the system evolves.

I think the best solution is an open API that we can send requests to that spits out JSON results
[GraphQL API ](https://fontawesome.com/v6/docs/apis/graphql/get-started) seems to be the solution to THAT item
that way we could just integrate whatever html structure is needed across WordPress, Magento and Shopify
drop in an AJAX call, and call it a day, trusting the API will always magically auto-update...

however, thats still something that needs to be engineered into complex themes across multiple systems
I've already got a system that works fine, it just needs a flat array

All that said?
The easiest thing for me to do at this point is still to strip down to a flat array and "drop" it into the core templates.
Ergo: just asking "hey, can you dump an array for us that have been supporting the system since before Font-Awesome/js-packages even existed? We like... have our own systems and stuff..."

From my perspective, it hardly seems like an even remotely unreasonable request.

Coming here and having other developers tell me "write even MORE code then!" after having spent 100s of hours since 2015 writing my own JSON/AJAX system (the first version of which took the CSS FA file, parsed and then stripped it down to an array before the JS layer even existed) feels... rude when all I am asking for is a simple flat JSON array.

[cvrocha]

check the metadata