coffeeispower
commented
1 year ago Fork pra favoritar cm assim? Pra favoritar r com uma estrela.
Open silvaezequias opened 2 years ago
coffeeispower
commented
1 year ago Fork pra favoritar cm assim? Pra favoritar r com uma estrela.
leocunhadev
commented
1 year ago Eu acho que o fork não foi um bom exemplo, talvez a Star se encaixe melhor, seria só uma forma de não perder o conteúdo após lido.
rCirelli
commented
1 year ago Pessoal, estou tentando implementar essa feature. Coloquei o botão para adicionar aos favoritos abaixo dos botões de tabcoin. Estou com dificuldade em entender a estruturação do backend da aplicação pra poder fazer a nova rota da API.
Inicialmente eu estava pensando em uma implementação simples, sem as funcionalidade de diversas listas de itens salvos. Mas ja estruturada para evoluir para isso, então com uma tabela com a seguinte estrutura:
(O valor adicionado à lista poderia ser um objeto com algumas outras informações além do slug do conteúdo)
Ao clicar em salvar, seria verificado se o ususário possui uma lista. Se sim, adicionaria o slug do conteúdo à lista. Se não, criaria uma lista com nome padrão e adicionaria o slug a essa lista. Inicialmente só seria possivel ter a lista padrão, pra pelo menos ter a implementação basica. Depois poderia ser adicionada a funcionalidade de criar multiplas listas.
O que acham?
Esta seria minha primeira contribuição com um projeto open-source, então quem puder dar uma luz eu agradeceria imensamente!
Estou continuando a discussão aqui e não na issue que abri (#1229).
Viniciusadm
commented
1 year ago @rCirelli como tá indo a implementação? Eu estava pensando nisso hoje, mas decidi procurar antes e encontrei essa issue.
AdrianKnapp
commented
1 year ago @rCirelli @silvaezequias @aprendendofelipe @Viniciusadm Como está o desenvolvimento dessa Issue?
Estou usando aplicativos como Instapaper, por exemplo. Para conseguir salvar artigos interessantes, e gostaria de contribuir com uma ferramenta para salvar/favoritar pots nativamente na plataforma do TabNews. Algo como o amigo descreveu acima.
Existe algo estruturado no back-end? Se sim, qual as rotas? Se não, como funciona para essas rotas em funcionamento? Pois para começar o front, precisamos disso estruturado.
anderood
commented
1 year ago @rCirelli @silvaezequias @aprendendofelipe @Viniciusadm Alguma novidade sobre este item?
Esta uma issue (acredito eu) de interesse de muitos, o que pode estar faltando pra realizar a implementação?
eletroswing
commented
9 months ago Olá, visto que essa feature como está seria algo muito grande de se fazer por si só e tornaria muito complicado o code review para os mantenedores do tabnews, o que acham de transformar essa feature(grande) em 3 novas features(com complexidade mediana).Poderiamos fazer algo como:
implementação 1: O usuario salva as publicações em local storage e so pode ver as proprios posts salvos, não teria o sistema de playlists e partiria de um unico dispositivo
implementação 2: a rota de api é adicionada, fazendo com que o usuario possa ver seus posts salvos atraves de diferentes dispostivos, porem ainda nao pode compartilha-los ao mundo nem criar playlists
implementação 3: a rota de api é melhorada dando suporte a playlists, e, assim, tornando a visualização das playlists e bookmarks publicas, onde um usuario pode ver, mas nao modificar a playlist de outro usuario
O que acham de partirmos assim?
Rafatcb
commented
9 months ago @eletroswing acho que não precisa separar tanto assim. A implementação 1 me parece pouco útil e traria a preocupação em sincronizar com o servidor na próxima implementação para o usuário não perder tudo. A implementação 2, de não deixar as listas públicas, parece também uma simplificação mínima, porque provavelmente o que diferenciará uma lista pública de uma privada é uma coluna na tabela.
Se quiser simplificar, pode fazer um PR para o frontend (UI) e outro para o backend (API), por exemplo. Nessa situação, recomendo fazer o de backend primeiro.
Sobre a sugestão do @rCirelli (https://github.com/filipedeschamps/tabnews.com.br/issues/645#issuecomment-1462736143), não acho que um array é melhor do que um relacionamento com outra tabela para essa situação. Não vi se teve um argumento a favor do array.
eletroswing
commented
9 months ago Compreendi e de fato é uma otima partida.
Sobre a segunda parte: Você acha que seriam necessários duas tabelas (uma, por exemplo, para as playlist que referencia a um user e outra referenciando os posts a uma playlist) ou, partir direto para uma tabela so de posts salvos ligadas a um usuario, sem essa intermediação de uma ´playlist´ na tabela?
acredito que partir tendo 2 tabelas, apesar de parecer mais complexo, seja mais simples de se manter.
Rafatcb
commented
9 months ago @eletroswing refleti um pouco para responder sua dúvida e acho que acabei chegando na mesma conclusão que você.
Eu enxergo dois cenários levemente distintos:
Isso implica que não existirá "listas de usuários", apenas "listas de conteúdos". Faz sentido para mim, não sei se alguém tem um contraponto.
Para um usuário criar listas com conteúdos, parece algo simples:
users ----- lists ----- contents
Já para um usuário seguir outros usuários, imagino o seguinte:
users ----- followers
Onde followers teria o id do usuário que está sendo seguido e do usuário que está seguindo.
O nomes das novas tabelas acima foi apenas para exemplificar.
Se formos considerar que um usuário poderá seguir listas de outros usuários, talvez complique um pouco mais. Não sei se isso será permitido, mas pode fazer sentido. Não pensei agora no que precisaria ser modificado na prática para atender esse requisito.
eletroswing
commented
9 months ago Acho que vou dar inicio pra adicionar essa feature de salvar no backend. Pensei um pouco nas rotas e acredito que possam ser assim: /bookmarks - POST cria /bookmarks/username GET - exibe as playlists de um user /bookmarks/username/id GET - exibe a playlist DELETE destroi e PUT faz update /bookmarks/username/id/user/slug POST - adiciona o conteudo na playlist DELETE remove o post da playlist
nessa ultima rota ainda estou com duvida, pois teria vários argumentos em uma unica rota, nao sei se passar o id real do conteudo seria uma boa ideia, ou se passar no body seria a melhor opção. mas pra quem lê as rotas, parece ser mais fácil de entender e interagir
Para seguir os usuarios pensei em tipo: /follow/username - GET - exibe a lista de pessoas que a pessoa esta seguindo, e segue em dois objetos: following e followers, poderia ter um filtro para pegar somente o que se é necessario, como:
/follow/username?followers=true&following=false, retornando so um dos objetos
/follow/username - POST - começa a seguir a pessoa DELETE - para de seguir a pessoa
Rafatcb
commented
9 months ago @eletroswing eu refleti um pouco mais e percebi que relacionamentos N:N vão acabar demandando mais uma tabela. Bom, você perceberá as necessidades conforme desenvolver.
Não sei se bookmarks é o nome mais adequado, mas acho melhor debater esse tipo de detalhe no próprio PR.
Também não sei se mostrar os seguidores de <alguma-coisa> é algo útil ou se sequer deveria ser público. A princípio, creio que nem precise implementar um endpoint ou função para isso. Pode focar no básico.
Andei pensando mais sobre o assunto e não sei se nós estamos nos confundindo em algumas funcionalidades aqui...
Para criar uma implementação inicial é interessante ter tudo em mente para não fazer algo que dificulte a evolução, mas creio que para a funcionalidade de "lista de conteúdo" inicialmente só precisemos do ponto 1 e, como um extra, o 2.
eletroswing
commented
9 months ago *dado o escopo, abordarei seguir e playlist como 2 features distintas que se completam, mas que nao precisam uma da outra
Sobre a de listas: Realmente 2 tabelas seriam necessárias nesse caso, uma para linkar uma playlist a um user e outra pra lincar um post a uma lista, até tem como fazer como mencionado anteriormente e usar um varchar[], mas acho que não seria o melhor nesse caso.
Sobre a feature de seguidores, estou pensando em algo como a seguinte estrutura pra tabela:
user_id: ser um campo que liga o evento de seguir a um usuario
target_id: seria o id alvo do objeto seguido
type: um campo texto para identificar o tipo do seguidor, seja pra seguir USER | CONTENT | TAG | LIST etc
e um campo da data de criação pra mensurar futuramente(se necessario), a partir de quando o usuario segue tal conteúdo
e para evitar duplicidade uma uniqueness_fkey que pegue ("user_id", "type", "target_id"), assim garantiremos que o objeto é unico
eliasnsz
commented
7 months ago Opa pessoal, entrando aqui pra saber como está a situação da feature de Favoritar conteúdos.
Esse é meu primeiro contato com o open-source então dicas e orientações são muito bem-vindas!
Estava trabalhando numa possível implementação dessa feature e me deparei com o post de boas práticas pra criar um PR do @rodrigoKulb. Então vim pesquisar pra ver se já tinha alguma issue com relação a esse tema e cheguei aqui.
Bom, indo direto ao ponto eu fiz algumas alterações e gostaria da opinião de vocês.
A implementação que eu pensei se baseia em uma nova tabela favorites que relaciona o ID do conteúdo com o ID do usuário.
Criei uma nova rota em api/v1/[username]/favorites que quando chamada com GET retorna a lista de conteúdos favoritados pelo usuário, já com paginação.
No model content.js alterei um pouco a construção da função 'findWithStrategy()' para que ela recebesse uma nova estratégia chamada favorites e um userId retornando assim a resposta que citei acima.
No front-end minha ideia foi de criar uma nova aba no perfil do usuário onde se localizariam os favoritos:
![](https://i.imgur.com/Js8uaHQ.png")
E naturalmente, os posts teriam um botão de favoritar que eu optei por adicionar no canto superior direito
Ainda não trabalhei na parte POST da api para favoritar o conteúdo, que na minha ideia ficaria localizado em
POST -> /api/v1/[username]/[slug]/favorite
Mas a parte GET está funcionando, inserindo manualmente os dados no banco, tudo funciona como esperado. Eu acho🤣
Reforçando que é minha primeira interação no mundo open-source, então gostaria de saber se estou no caminho certo, se fiz demais, se fiz errado, se fiz antes da hora, qualquer feedback é bem-vindo, de verdade!
Obrigado povo
Rafatcb
commented
7 months ago @eliasnsz muito legal seu progresso, parabéns!
Se me permite sugerir uma mudança, seria tratar essa funcionalidade com listas (no plural), ao invés de uma única lista ("favorito"). Isso adiciona mais complexidade, mas é a funcionalidade "alvo" que estamos buscando com esse issue.
Sua sugestão de implementação de UI no perfil está bem próxima do que eu imaginei que seria! Só mudaria o fato de existirem várias listas (mas eu continuaria deixando uma única aba). Não cheguei a pensar como seria a visualização do conteúdo presente em uma lista.
Reforçando que é minha primeira interação no mundo open-source, então gostaria de saber se estou no caminho certo, se fiz demais, se fiz errado, se fiz antes da hora, qualquer feedback é bem-vindo, de verdade!
Não sei se você já tinha visto este issue antes de começar a implementação, mas é sempre bom buscar o que foi discutido antes de iniciar, principalmente quando é algo complexo.
Mas eu não diria que você está errado em ter feito algo. Se ter alguma dúvida pode comentar que eu e o @aprendendofelipe buscamos orientar da melhor forma possível, e também tem outras pessoas que ajudam a responder as dúvidas e sugestões nos issues. Como gostamos de dizer, "mesmo um PR recusado pode trazer ensinamentos para uma implementação futura", a discussão é benéfica.
Por fim, não se sinta obrigado em fazer algo. Ao mesmo tempo em que ficamos felizes em receber colaborações no repositório, de forma alguma "exigimos" que alguém comece e termine uma funcionalidade, por exemplo, ou que se comprometa com a entregar algo num determinado tempo. Já aconteceu algumas vezes de uma pessoa aparecer, colaborar, e um mantenedor do repositório concluir e integrar a solução. Trabalho em equipe :smile:
dudubass15
commented
5 months ago Pessoal, alguma novidade sobre a implementação dessa nova funcionalidade? Algo que posso ajudar?
Estava acessando a aplicação hoje e queria salvar algumas postagens e ai fui parar aqui e ver que ainda está sendo desenvolvida essa solução.
HarukaYamamoto0
commented
2 months ago Bom dia, também gostaria de saber o status dessa issue, principalmente da feature de seguir um usuário, pois atualmente para fins de estudo estou criando um client para o Tab usando compose e gostaria de adicionar essa feature nele
Até pensei em fazer esse sistema criando meu próprio servidor onde a cada x tempo ele verificaria se tem novidades, mais logo cheguei a conclusão que seria inviável pois provavelmente eu iria tomar rate-limit se muitos usuários usassem o app
Já para um usuário seguir outros usuários, imagino o seguinte:
users-----followersOnde
followersteria oiddo usuário que está sendo seguido e do usuário que está seguindo.
Sobre isso não seria mais fácil apenas colocar dois arrays followers e following dentro do user onde conteria apenas os ids usuários dos respectivos campos?
E sobre seguir um conteúdo acredito que não faça tanto sentido, por exemplo se um usuário comentar em um artigo, em tese o único que é para receber essa notificação é para ser o dono do artigo, a menos que esse comentário seja uma resposta, a outro comentário, e sobre receber a notificação ia ser bom poder que os clients podessem ouvir esses eventos também
E também sobre seguir tags, em larga escala isso não tornaria quasse um spam se muitos usuários publicarem artigo com tags? talvez se fosse ser notificado com um email tipo Top #Pitch da semana, em vez de necessariamente receber notificação de cada novo artigo com essa tag
Esses são meus pontos de vista e minhas dúvidas, se eu tiver errado por favor me diga, pois eu não tenho experiência com sistemas mais complexos, então gostaria de poder entender essas decisões
Edson5-spec
commented
1 month ago A função de guarda os posts que vc mais gosta só está no app mas e no site
Vai ser colocado no site ou vai ficar msm só para app?
Contexto
Navegando pelo TabNews eu me deparei com conteúdos incríveis e de extrema utilidade, só que eu senti falta de uma opção de salvar aquele conteúdo para que eu possa acessar ele mais tarde sem precisar procurar ele no feed.
Favoritar Conteúdos
A minha sugestão é de adicionar uma feature de
Conteúdos Favoritos, onde em cada conteúdo (rootouchild) teria uma opção de favoritar, igual os exemplos a seguir:A opção de
Forkdo Github."Questões Favoritas" do Stackoverflow
Nova Rota na API
/favoritosComo consequência, teria que criar nova rota com os conteúdos favoritos do usuário que, obviamente, listaria todos os conteúdos favoritos do usuário... E inicialmente, eu acho melhor deixar privado os conteúdos favoritos somente para os usuários que estão conectados na sessão. (isso pode até ser uma opção do usuário, deixar público ou privado)
Sandbox
Uma ideia maluca que eu tive mas que pode ser útil (talvez) é: em vez de criar uma feature de Favoritos, criar um sistema de
ContentListonde o usuário poderá criar quantas listas quiser com diversos conteúdos adicionados à ela, assim como as playlists do Youtube, por exemplo. Isso ajudaria bastante na questão de organização, principalmente pra quem publica sequências de conteúdos didáticos e etc...