[Community Help Wanted] Help QA the new & improved Tutorial!

obi-wan

The Redwood v1 Launch :rocket: is fast approaching and we need your help!

@rob has revamped both Tutorial I & II for v1 RC and we need you, our amazing community members, to help QA the new & improved version to ensure the Tutorial is as amazing as ever. :sunglasses:

:zap: TL;DR


:question:What we need from you

Head over to redwoodjs.com:arrow_upper_right: and start the Tutorial!

As you work your way through make note of typos :fountain_pen:, sections that are confusing :thinking:, instructions or code that do not work as expected :person_gesturing_no: , bugs you find :lady_beetle: - any & all hiccups you run into.

We want to know about it. If you’re struggling, chances are someone else is too.

:test_tube: Types of tests we’re looking for:

  • :hash: Different Node versions (Redwood is compatible with v14 → v16)
  • :desktop_computer: Operating Systems - Windows, Mac, Linux
  • :closed_book: Walk through Tutorial I
  • :green_book: Walk through Tutorial II based on self-built Tutorial I
  • :blue_book: Tutorial II based on the sample repo (The sample repo is the final state of Tutorial I)

:exclamation:Reporting an Issue

If you find something…

Be sure to include the following in your report:

  • :hash: Node Version
  • :desktop_computer: OS
  • :keyboard: any commands that failed
  • :x: error messages
  • :camera_flash: screenshots
  • :open_book: which part of the Tutorial you were working on
  • etc…

:thought_balloon: Final Thoughts

Feel free to reach out to core team members here in the forums :fountain_pen:, on our tracking issue :spiral_notepad:, or on Discord :speech_balloon:, if you need any assistance.

Go forth and help make Redwood even better. :woman_technologist:t2::man_technologist::rocket:

By helping each other be successful with Redwood, we make the Redwood project successful. :heart:


Survey

If you plan to help QA on the Redwood Tutorial, please let everyone know what you’ll be covering by checking all applicable items below. And Thank You! in advance.

  • (OS) MacOS
  • (OS) Windows
  • (OS) Linux
  • (Node.js) v14
  • (Node.js) v16
  • Tutorial Part 1
  • Tutorial Part 2 (using project code from Tutorial Part 1)
  • Tutorial Part 2 (using the pre-built Redwood Tutorial repo)
  • Completed QA on either Part 1 or Part 2

0 voters

Spread the Word

Lastly, please help us tell others about this request. You can use one of the templates below or create your own, just be sure to include the link to this post for details:

https://community.redwoodjs.com/t/community-help-wanted-help-qa-the-new-improved-tutorial/2825

Suggestion One

Share the following Tweet

I just helped QA the new @redwoodjs v1.0.0 Tutorial! And you can help, too :point_down:
[Community Help Wanted] Help QA the new & improved Tutorial!

Suggestion Two

Share the following Tweet

The best way to learn @redwoodjs is the new Tutorials part 1 and 2, updated for version 1.0.0. This week the community is helping to QA the updates. And we need your help! :point_down:
[Community Help Wanted] Help QA the new & improved Tutorial!

5 Likes

I’m a little bit curious here @rob why did you not use the new “Service Validations” to validate the contact email(see image below)

2 Likes

Rob can confirm but it might be related to an issue that I’m currently working on where service validations don’t set the error message on the form field.

Which I intend to address before v1

1 Like

I am going through the current Tutorials (I and II) with very fine comb, since couple weeks ago. It would help me to know the version of Tutorials - v0.45.0 at this moment to be displayed the learn.redwoodjs.com page) and to keep this version unchanged until the WA of Docs ends).

I order to be of most help, I will redo my testing / verification as soon as the docs version is announced. I also suggest that each tester defines the output of yarn rw info as this tester’s signature: (mine is this)

 yarn rw info              
yarn run v1.22.17
$ /Users/nik/dev/pacific-north/initialize/redwoodblog/node_modules/.bin/rw info
(node:65988) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

  System:
    OS: macOS 12.2.1
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.1 - /var/folders/y3/n2p741pj7vq9ckj9jrmlbp6m0000gn/T/yarn--1646585440471-0.3586255412744028/node
    Yarn: 1.22.17 - /var/folders/y3/n2p741pj7vq9ckj9jrmlbp6m0000gn/T/yarn--1646585440471-0.3586255412744028/yarn
  Databases:
    SQLite: 3.36.0 - /usr/bin/sqlite3
  Browsers:
    Chrome: 98.0.4758.109
    Firefox: 96.0.3
    Safari: 15.3
  npmPackages:
    @redwoodjs/core: ^0.46.0 => 0.46.1 

I am discussing with @thedavid a creation of a task that is closely related to tutorials, designed to explain various debugging techniques, using the tutorial’s blog application as it’s domain.

Going through the tutorial I found myself wishing that such debugging tutorial already exists, so I plan that in my second consecutive pass through QA I also write that debugging tutorial.

In order to avoid any interference with the QA project, I would prefer to write it “locally”. It would be nice if I could create this document in the same identical format as RW Docs.

Question: is there a document describing the format and tools used to write RW Docs?

Yep, the issue @dthyresson linked to is the reason! If we get that updated before 1.0 I’ll update the tutorial to use Service Validations.

While not debugging per se, the best way I know what my code is doing is to write tests and to use Wallaby and its output inspector that gives me live values to see.

I find it more useful than a breakpoint and step debugger to be honest — and we should be writing tests as well.

@dthyresson, I like your wallaby suggestion a lot and will use it immediately, not only in the context of Tutorial QA.

I also strongly advise testing (with the caveat that I respond with "don’s look at what I am doing, listen to what I am telling). This is probably my best chance ever to do what I am advising other to do, so thanks for the nudge.

In order to get better initialized to use Wallaby and tests, help me with the advice on how to move ahead with my current issue:

I typed in all of the code explained in Authentication section, and using the signup page, defined my ID (as nik@congral.com) and password (as AnnArbor2022), not getting any error indications.

Now trying to get authenticated via Login page, I am getting this:

image

The error message most likely coming from Login page, so my best approach is to used the debugger (the VSCode / Chrome combo), find my last line of code which triggers this error and then using bisection find where in RW run time this happens.

I do agree with you David that this type of error (me supplying possible erroneous input) should be reported better than what I am currently getting (object which’s findUnique I try to invoke being null)

As this might be a discussion interesting to many, please respond to my questions.

Actually, the page won’t surface an error, the dbAuth serverless authentication handler is doing that – you’ll see in the network response the error returned.

It’s likely from

It’s a Prisma and database related error where somehow your this.dbAccessor or Prisma Client is not valid.

Have you generated the Prisma Client after modifying schema?

Does yarn rw prisma generate and restarting the dev server correct it?

This actually shows me of an issue in error handling.

In GraphQL we’d mask this error to prevent you seeing it’s a Prisma related and a database error.

But, since this is serverless function, these errors aren’t masked nicely Sio sensitive info can leak.

1 Like

Thank you for these hints:

It’s a Prisma and database related error where somehow your this.dbAccessor or Prisma Client is not valid.
Have you generated the Prisma Client after modifying schema?
Does yarn rw prisma generate and restarting the dev server correct it?

I do not believe that I regenerated the Prisma client after modifying the schema - probably was interrupted following the tutorial steps and when returning, my own state (as managed in my head) was incorrect.

Such problem is not easy to solve unless one has a lot deeper understanding of all transitions in the code caused by invoking a “cli-step” between your own writing the JavaScript / TypeScript code, step which dramatically changes the state of our app.

Equally important is this:

This actually shows me of an issue in error handling:

In GraphQL we’d mask this error to prevent you seeing it’s a Prisma related and a database error.
But, since this is serverless function, these errors aren’t masked nicely Sio sensitive info can leak.

I do not want to continue this discussion under the topic “Help QA the new & improved Tutorial!”, as this subject is a lot more general. So, I will make a note in my own log being kept in “Tutorial QA” and will resurface it at a better time

@giannelli.tech - my direct response to your RW tutorials QA invitation is written here to avoid pollution of your original invitation to start the QA. As you will see, I created a more structured approach using my QA Github repo, which will allow me to share my code with other tester’s code.

1 Like