Read JSON File - Server Action

Feature Request
1

It would be great to be able to specify a path to a local JSON file that can be read and used with server actions. I have standard lists e.g. for contact titles or country names/codes which come in useful during Server API actions.

I appreciate that there is a workaround for this:

But this has a limitation when the file needs to be private so the API step will not be able to resolve it as a public URL.

I also feel as though it should be easier - adding the step and using the file picker to choose the relevant file

2

Ben, can you expand on that, specifically how you envisage the json file being used once read. Should be an easy extension although a schema for the picker may be problematic as hjson does not support dynamic schemas

3

Hi Brian,
I'm sure it would be relatively easy to do as an extension but I can hardly believe that it doesn't already exist natively in Wappler (that primarily works on JSON)

I have some files that I use as the basis of standard lists that often do the translation from codes to human-friendly or populate select inputs etc. Mostly this is on the front-end and the JSON AC component works. There are, however, times when I want to access the same lists server-side e.g. when using data to generate emails/notifications that need to be human-friendly (it is possible but fiddly to use the API step for this). I also have some cases where I want to have lists, for similar code translations, that are server-side only without placing the json file in a publicly accessible folder - this is not possible using the API step

e.g.

"enquiryheats": [
        {
            "code": "0",
            "desc": "None (0% - Make the enquiry 'Lost')",
            "color": "rgba(173,49,158,0.5)"
        },
        {
            "code": "20",
            "desc": "Little chance (0-20%)",
            "color": "rgba(79,84,146,0.5)"
        },
        {
            "code": "40",
            "desc": "Low chance (20-40%)",
            "color": "rgba(79,137,146,0.5)"
        },
        {
            "code": "60",
            "desc": "Moderate (40-60%)",
            "color": "rgba(255,193,7,0.5)"
        },
        {
            "code": "80",
            "desc": "Highly possible (60-80%)",
            "color": "rgba(255,121,7,0.5)"
        },
        {
            "code": "100",
            "desc": "Certain (80-100%)",
            "color": "rgba(220,53,69,0.5)"
        }
    ],
"countries": [
        {
            "code": "GB",
            "desc": "United Kingdom"
        },
        {
            "code": "AF",
            "desc": "Afghanistan"
        },
        {
            "code": "AL",
            "desc": "Albania"
        },
        {
            "code": "DZ",
            "desc": "Algeria"
        },
        {
            "code": "AS",
            "desc": "American Samoa"
        }
// shortened for posting
]
4

Yes, it does seem a strange omission.

The big issue is schemas. The hjson definition methodology means the schema is static and fixed. It can't be manipulated to match the returned data's keys. I assume the team could do that with the wappler code

Reading a json file and returning it as a useable json object should not be difficult but with the current tools it is not possible to dynamically generate a picker schema.

This means objects would required to be referenced manually i.e. for an object called jdata andvyout data this would be:
jdata.code, jdata.desc, jdata.color

No picker to assist!

It's a road block i have hit a few times.

If it would assist i will look at what i can come up with or you may prefer to wait for the team to add this as a full solution.

1 Like
5

Thanks Brian,
I think it would be in everyone’s interest to have a fully native solution. The schema can be auto generated in the existing API step so I’m sure it wouldn’t take too much for them to do the same from a JSON file. It’s doing roughly the same thing but from a local path rather than a URL :crossed_fingers: