tabnews.com.br
tabnews.com.br copied to clipboard
filipedeschamps
Listas personalizadas de Conteúdos, Comentários e/ou Usuários (e futuramente Tags), seja para Seguir com Notificações ou apenas Favoritar
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 (root ou child) teria uma opção de favoritar, igual os exemplos a seguir:
-
A opção de
Forkdo Github.
-
"Questões Favoritas" do Stackoverflow
- "Favoritos" do próprio Google.
Nova Rota na API /favoritos
Como 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 ContentList onde 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...
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.
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.
https://user-images.githubusercontent.com/22369220/224143708-e6473401-8f93-48fc-9170-5626cb202cc6.mp4
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).
@rCirelli como tá indo a implementação? Eu estava pensando nisso hoje, mas decidi procurar antes e encontrei essa issue.
@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.
@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?
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?
@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.
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.
@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:
- Um usuário pode colocar conteúdos em diferentes listas.
- Um usuário pode seguir outros usuários.
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.
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
@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...
- Usuários poderão criar listas de conteúdos para organizarem as publicações e comentários como quiserem.
- Usuários poderão ver listas de conteúdos públicas criadas por outros usuários.
- Usuários poderão seguir usuários para serem notificados de novas publicações/comentários.
- Usuários poderão seguir tags para serem notificados de novas publicações.
- Usuários poderão seguir conteúdos para serem notificados de comentários/edições.
- ❓ Usuários poderão seguir listas de conteúdos. Não sei se isso faz sentido, seria para que? Para ser notificado quando o dono da lista adicionar algo novo? Vendo por esse lado, pode ser interessante.
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.
*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
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:
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
@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:
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.
