verdnatura/hedera-web
verdnatura
/
hedera-web
0
1
Fork 3
Code Issues Pull Requests 4 Releases Wiki Activity

refactor: migrate fetchUser API call from PHP to Salix #111

Merged
jsegarra merged 5 commits from ldragan/hedera-web:taro/migrate-fetchUser into beta 2025-03-13 08:08:36 +00:00
Conversation 0 Commits 5 Files Changed 1 +4 -5
1 changed files with 4 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/stores/user.js
View File

@ -248,11 +248,10 @@ export const useUserStore = defineStore('user', () => {
const fetchUser = async (userType = 'user') => { const fetchUser = async (userType = 'user') => {
try { try {
const userData = await jApi.getObject( const userData = await api.get('VnUsers/getCurrentUserData');
ldragan marked this conversation as resolved Outdated
jsegarra commented 2025-02-18 08:04:41 +00:00
Outdated
Review
Copy Link

duda: porque el _?

duda: porque el _?
'SELECT id, nickname, name, lang FROM account.myUser'
ldragan marked this conversation as resolved
jsegarra commented 2025-02-18 08:07:03 +00:00
Review
Copy Link

El token no es necesario porque está definido que se coja en boot/axios
De esta manera evitamos que hacer getToken y pasarlo como parametro de la petición.
Prueba a quitarlo y me dices si obtienes el mismo resultado. Si no comentamos

El token no es necesario porque está definido que se coja en boot/axios De esta manera evitamos que hacer getToken y pasarlo como parametro de la petición. Prueba a quitarlo y me dices si obtienes el mismo resultado. Si no comentamos
ldragan commented 2025-02-19 05:14:23 +00:00
Review
Copy Link

Tenés razón. Probé quitarlo y anda perfecto.

En renewToken se pasa de forma explícita, pero también se autentica con el _tokenMultimedia. Supongo que en ese caso tiene sentido, incluso si redundante, para esclarecer posibles dudas comunicando intención deliberada:

        const _token = getToken();
        const tokenData = await api.post('VnUsers/renewToken', {
            headers: { Authorization: _token }
        });

        const _tokenMultimedia = getTokenMultimedia();
        const tokenMultimedia = await api.post('VnUsers/renewToken', {
            headers: { Authorization: _tokenMultimedia }
        });
Tenés razón. Probé quitarlo y anda perfecto. En `renewToken` se pasa de forma explícita, pero también se autentica con el `_tokenMultimedia`. Supongo que en ese caso tiene sentido, incluso si redundante, para esclarecer posibles dudas comunicando intención deliberada: ```js const _token = getToken(); const tokenData = await api.post('VnUsers/renewToken', { headers: { Authorization: _token } }); const _tokenMultimedia = getTokenMultimedia(); const tokenMultimedia = await api.post('VnUsers/renewToken', { headers: { Authorization: _tokenMultimedia } }); ```
); if (userType === 'user') mainUser.value = userData.data;
ldragan marked this conversation as resolved Outdated
jsegarra commented 2025-02-19 08:04:34 +00:00
Outdated
Review
Copy Link

necesitaré mas info sobre esto. porque no tenemos console.error hechos de esta manera sino que estan dentro de trycatch
Axios ya tiene manejador para los errores

necesitaré mas info sobre esto. porque no tenemos console.error hechos de esta manera sino que estan dentro de trycatch Axios ya tiene manejador para los errores
ldragan commented 2025-02-20 07:55:42 +00:00
Outdated
Review
Copy Link

Aquí estoy siguiendo el patrón de fetchTokenConfig, que, cuando el server retorna un algo falsey, simplemente termina temprano:

    const fetchTokenConfig = async () => {
        try {
            const { data } = await api.get('AccessTokenConfigs/findOne', {
                filter: { fields: ['renewInterval', 'renewPeriod'] }
            });
            if (!data) return; // <--- AQUI
            tokenConfig.value = data;
            storage.value.setItem('renewPeriod', data.renewPeriod);
            return data;
        } catch (error) {
            notify('errors.tokenConfig', 'negative');
            console.error('Error fetching token config:', error);
        }
    };

Pero le agrego un console.error para no perder completamente el registro. Si tienen Sentry o afines, podrán ver ese log en producción. De lo contrario, solo servirá para debugging.

Por otro lado, por lo que estoy viendo, parece ser imposible que !userData, y !userData.data es técnicamente posible (Axios declara T = any), pero eso implicaría que

  • el server retornó algo que no es un objeto JSON, en cuyo caso, asumo, Axios tiraría error,
  • se configuró Axios con algún transformador post-respuesta que retorna algo falsey, lo cual, probablemente, sería un bug

Así que este chequeo parece redundante. Lo quitaré.

En el caso que tomé de ejemplo, además de las otras razones, esto es una llamada a AccessTokenConfigs/findOne sin filtros, y entiendo que nunca ocurrirá que no exista ningún solo registro en esa tabla. Así que, imagino, deberíamos poder quitar esa verificación en ese caso. Pero bueno, eso sería para otro PR.

Aquí estoy siguiendo el patrón de `fetchTokenConfig`, que, cuando el server retorna un algo falsey, simplemente termina temprano: ```js const fetchTokenConfig = async () => { try { const { data } = await api.get('AccessTokenConfigs/findOne', { filter: { fields: ['renewInterval', 'renewPeriod'] } }); if (!data) return; // <--- AQUI tokenConfig.value = data; storage.value.setItem('renewPeriod', data.renewPeriod); return data; } catch (error) { notify('errors.tokenConfig', 'negative'); console.error('Error fetching token config:', error); } }; ``` Pero le agrego un `console.error` para no perder completamente el registro. Si tienen Sentry o afines, podrán ver ese log en producción. De lo contrario, solo servirá para debugging. --- Por otro lado, por lo que estoy viendo, parece ser imposible que `!userData`, y `!userData.data` es técnicamente posible (Axios declara `T = any`), pero eso implicaría que - el server retornó algo que no es un objeto JSON, en cuyo caso, _asumo_, Axios tiraría error, - se configuró Axios con algún transformador post-respuesta que retorna algo falsey, lo cual, probablemente, sería un bug Así que este chequeo parece redundante. Lo quitaré. --- En el caso que tomé de ejemplo, además de las otras razones, esto es una llamada a `AccessTokenConfigs/findOne` sin filtros, y entiendo que nunca ocurrirá que no exista ningún solo registro en esa tabla. Así que, imagino, deberíamos poder quitar esa verificación en ese caso. Pero bueno, eso sería para otro PR.
if (userType === 'user') mainUser.value = userData; else supplantedUser.value = userData.data;
else supplantedUser.value = userData;
} catch (error) { } catch (error) {
console.error('Error fetching user: ', error); console.error('Error fetching user: ', error);
} }