Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Feedback on JS 4 (APIs part 1)

Aberta
#262 2 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
30/100
Tipo de issue
Documentação
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
javascript
Domínio
documentation

Direção de pesquisa

Start by reviewing JS 4 (APIs part 1), especially the script.js examples and the showUser/showError callbacks. Compare the synchronous and async sections, then assess how the functions and exercises are introduced. Done means the tutorial explains code placement and wiring clearly, handles the reported callback issues, and has a manageable exercise flow.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

I coached this last week and had the following notes:

  • It wasn't initially clear where the JavaScript had to be written. Earlier tutorials have it written straight into the console - it wasn't obvious to the student that the code needed to go into a script.js.
  • It's not clear why event works within the example code when e is the passed argument in $(document).on('keypress', '#username', function(e).
  • When skim reading the tutorial, as students often do, it's not clear how to wire the various functions together. That said, I believe that encouraging this thinking is useful at this point, so maybe that's ok. It just might be worth explaining in the text how the wiring between functions should work for those that do read/are not being coached
  • It confused the student when they had to replace an existing function with an expanded version
  • If the user is not found on GitHub, we ask to show an error with the username... but within the showUser function this is not available.
  • Overall the responsibility of showUser is weird because it takes an instance of XMLHttpRequest, not a user. When we switched to async it was obvious to create a second callback of showError, but again sending the username to that callback is non-trivial without using a closure which the student is likely not ready for.

Overall the tutorial is flowing better since the recent rewrite, and I think the decision to do the github request synchronously at first is sound. That said, I think it would be better to more explicitly "break" the code by switching it to async and letting the student understand the problems that follow with code that relies on blocking.

One last thing: you never, EVER get to the second exercise, even with an advanced student and 1:1 coaching. Perhaps it needs splitting? That said, this is an issue with several tutorials (eg intro to jQuery) and students are used to continuing the same module over several weeks. It just might give a better sense of achievement to "finish" a tutorial and then move on, as is possible in HTML and CSS.

Linguagem predominante
JavaScript
Estrelas
268
Forks
240
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de codebar/tutorials

Todas as issues de codebar/tutorials

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.