[MYSTERY SOLVED] REST API: How to simply GET a record usinf frappe-ui?

avc · January 14, 2025, 4:21pm

Here I am using frappe-ui

Jokes aside, we are building some little apps for different purposes (field force, HR checkin …). Best way to learn is diving the code of Frappe apps … LMS, HelpDesk, Gameplan, Drive …

frappefr · January 14, 2025, 4:22pm

You’re lucky! I usually blow every mine in the frappe-ui minefield.

avc · January 14, 2025, 4:30pm

FrappeUI is growing and pretty undocumented yet … but is fantastic and easy to learn.

This recent video from @buildwithhussain is really good too.

Peer · January 14, 2025, 5:53pm

There are different levels of abstraction and also a data hierarchy.

If you ask for a list, you get just the “names” of the documents: the unique doc references for the “rows” in a doctype table. So you can get a big list with little data. Then you can drill down to get documents.
With lots of data you also will need to include paging when advancing through lots of data.
You can pick fields, which can bring you between mere “names” (really IDs) and full documents including subtables. These documents can get big.
So with the need to navigate the tradeoffs between “many but small” and “just one but very big”, there are different possibilities to build stuff.

Also, if you get a doc, set some fields to new values and and then just “insert” or “put” or however the API calls its methods, then it also gets interesting because you can manage big docs (DT instances with many fields) with just some lines of code, and the complexity of big, complicated custom DTs is just kind of hidden behind some beautifully crafted lines of the nice framework.

So, all this software crafting has many interesting facets.

frappefr · January 14, 2025, 7:21pm

I may be wrong, but for the moment, I disagree. The three of them provide basically the same service when tailored with fields (when possible).

If they are used without fields, I don’t want a function (createListResource) to get only a cryptic list of names (0489l150rq, … because doctype don’t have to be tailored (Title field) based on the limitations of the API right?), then click randomly on one record to get (createDocumentResource) ALL the fields and beyond, even data that is not related to the doctype:

all the meta (allocated_to, … 17 lines of key-value pairs, many null or data that should not be visible by clients or guests)
the doctype history (originalDoc, 21 fields with a lot of nulls),
repetition of my request (28 lines)
“hidden doc” about functions (40 lines), useless since you can insert, update, delete without calling createDocumentResource (todos.insert.submit)

All this for EACH record (you can’t “pick fields” in createDocumentResource).
(count them in my post above [MYSTERY SOLVED] REST API: How to simply GET a record usinf frappe-ui? - #17 by frappefr)

That’s more than 100 key-value pairs not related to the doctype itself (3-6 useful fields in a todo).
Even if it was only for trusted clients, it’s already slow, I don’t want customers to GET all this (including name of staff who modified the record), then filter out everything on the client.
Hope this make more sense.

Peer · January 14, 2025, 7:40pm

I’d still say it depends on the use case.

You could have sales orders with hundreds of line items, even with photos.
Lag could be an issue.
You could build an archive app with extreme requirements.
A book app with thousands of scanned pages.
Or some other kind of data silo with many many detailed but small info bits (web logs, car flows, weather logs every minute over 30 years, you name it).
Requirements and limitations of can vary wildly.

Whatever, no need to argue, I wish you fun and success building apps with your framework and UI of choice.

peterg · January 15, 2025, 4:53am

Strange, it works fine for me. If you’re in a development environment, errors would go straight to the console via stdout. Are you not seeing them there?

That said, I agree fully with @avc that createListResource and createDocumentResource are usually better interfaces for frappe data. In FrappeUI, createResource is the generic http interface, and it works for both frappe and non-frappe data. It’s also used for calling system-level methods that aren’t tied to a specific doctype.

Others have explained why a List/Doc distinction exists, but one thing I’d add:

Just be careful here, because using createListResource to filter fields isn’t a protection. If you have data that you don’t want guests or customers to see, there’s no javascript solution to that problem. Your permissions configuration on the backend is the only thing that matters here.

avc · January 15, 2025, 6:37am

Soon this will be usable …

github.com/frappe/frappe-ui

feat: useCall, useList, useDoc

frappe:main ← frappe:use-doctype

opened 08:27AM - 20 Nov 24 UTC

netchampfaris

+2513 -184

- New data fetching composables based on @vueuse's useFetch - Based on `/api/v2…` ### useCall ```ts import { reactive, ref } from 'vue' import { useCall } from 'frappe-ui' interface LoginResponse { success: boolean message: string } interface LoginParams { usr: string pwd: string } let loginParams = reactive<LoginParams>({ usr: '', pwd: '' }) let login = useCall<LoginResponse, LoginParams>({ url: '/api/v2/method/login', method: 'POST', immediate: false, // don't fetch immediately refetch: true, // auto refetch when params change params: loginParams, transform(data) { return { success: data.message === 'Logged In', message: data.message } }, onSuccess: (data) => { console.log(data) }, onError: (error) => { console.error(error) }, }) await login.submit({ usr: 'admin', pwd: 'admin' }) login.data // { success: true, message: 'Logged In' } login.error login.loading login.abort() ``` ### useList ```ts import { reactive, ref } from 'vue' import { useList } from 'frappe-ui' interface User { name: string email: string full_name: string } let query = ref('adm') let users = useList<User>({ doctype: 'User', fields: ['name', 'email', 'full_name'], filters: { role: 'System Manager', name: ['like', query], }, start: 0, limit: 10, orderBy: 'name asc', refetch: true, // auto refetch when params change }) users.data // [{ name: '..', email: '..', full_name: '..' }, ..] users.loading users.hasNextPage users.hasPreviousPage users.next() users.previous() users.fetch() users.abort() ``` ### useDoc ```ts import { useDoc } from 'frappe-ui' interface User { name: string, email: string, first_name: string, last_name: string } interface UserMethods { getFullName: () => string updateEmail: (params: { email: string }) => void } let user = useDoc<User, UserMethods>({ doctype: 'User', name: 'user1', methods: { getFullName: 'get_full_name', updateEmail: { name: 'update_email', onSuccess() { console.log('email updated') } } } }) user.getFullName.submit() // typescript is happy user.getFullName.submit({}) // typescript errors user.getFullName.data // string | null (inferred from method definition in UserMethods) user.updateEmail.submit({ email: 'test@example.com' }) // typescript is happy user.updateEmail.submit() // typescript errors user.updateEmail.data // void | null (inferred from method definition in UserMethods) ```

frappefr · January 15, 2025, 7:51am

Maybe I don’t get what you meant, I didn’t mean to argue, I apologize.

frappefr · January 15, 2025, 8:03am

That’s what I get (server and browser console):

Maybe we don’t have the same versions?

erpnext 15.x.x-develop
frappe 15.x.x-develop
"frappe-ui": "^0.1.98"

The only error.log I have is worker.error.log:

I totally agree.
This raises another question: How to prevent certain (meta) fields to be read by certain users?
I don’t see this “permission by field” in the doctype. “Permissions” tab is for all records, fields don’t have this granularity.
Could you please show me an example @peterg?

Peer · January 15, 2025, 8:39am

Don’t worry; I said this to myself as well.
Our perspectives are somewhat different, I was looking from a point closer to the technical side, the transmissions and such, and you know more about the frappe UI, which I found (and find) interesting and inspiring: I’ll look into this more, but can’t do that ATM, but will probably need it at a later time.

peterg · January 15, 2025, 9:53am

It’s hard to say. You’re on a pre-alpha development branch, so anything could be the cause. If you want to troubleshoot, your best bet is probably to set some breakpoints with a debugger to see what’s going on.

https://docs.frappe.io/erpnext/user/manual/en/changing-the-properties-of-a-field-based-on-role

frappefr · January 15, 2025, 12:34pm

I didn’t choose it on purpose , just bench init
If stuff is not working on latest version, and we don’t know which frappe version was used to make apps and plugins, I wonder how to know what is supposed to work on what we have.

Thank you for the link, my bad!