Date: Sun, 23 Jan 2022 09:20:38 +0000
To: Simon Ser <contact@emersion.fr>
From: Renato Torres <renato.torres@protonmail.com>
Cc: ~emersion/hut-dev@lists.sr.ht
Reply-To: Renato Torres <renato.torres@protonmail.com>
Subject: Re: [PATCH v1 0/1] git: show license spike
Message-ID: <CHCXY7MI4TNI.15PV94O7IM34Q@mint2>
In-Reply-To: <VVEqWeSlVFfoMZ2hNXzVOcwM-VtrM6VF_vBqhaMIw4dtqyuGvleSLKbEU2Cxd8ync0sEEg0NfB3SzUYhdIZLRZ1eq0K9nUzT23bTaLVfi0I=@emersion.fr>
References: <20220122233022.1256016-1-renato.torres@protonmail.com> <VVEqWeSlVFfoMZ2hNXzVOcwM-VtrM6VF_vBqhaMIw4dtqyuGvleSLKbEU2Cxd8ync0sEEg0NfB3SzUYhdIZLRZ1eq0K9nUzT23bTaLVfi0I=@emersion.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


> Any other ideas?

The client can have an ExecuteRaw method to return json.RawMessage,=20
giving developers the possibility to decode the JSON in scenarios with
complicated nested interfaces:

func (c *Client) ExecuteRaw(ctx context.Context,
                            op *Operation) (*json.RawMessage, error) {
    // ...
}

The generate code in gql.go could be augmented with functions like:

func RepositoryByNameRaw(client *gqlclient.Client,=20
    ctx context.Context, name string) (message **json.RawMessage, err error=
) {

    // ...
}

This is not as friendly as having well defined structures but unlocks
the possibility to tackle cases we cannot forsee or quickly add support
to.

What do you think?