Testing Components > Manually handling lifecycle is not complete

[baerrach]

I'm submitting a bug report
https://aurelia.io/docs/testing/components#manually-handling-lifecycle

Current behavior:
The example for it('can manually handle lifecycle' is pasted within the my-component.spec.js file, but that component only has a .firstName in the view and not a .name, and the model has no lifecycle hooks that might rebind properties to append the lifecycle name into the view.

Expected/desired behavior:
I think this section needs to be rewritten and include the View/ViewModel specific for this example.

[EisenbergEffect]

@bigopon I think you worked most recently on the testing library. Does my memory serve me correctly? Would you be able to update the docs a little bit based on @baerrach ‘s feedback? He’s new to Aurelia and has been providing us with tons of great feedback (and fixes!) to help make our docs better for the community.

@baerrach On that note, we’re really grateful for how you’ve jumped in and started contributing. You may or may not know that a large part of our efforts are currently focused on Aurelia vNext (which we’ll probably just call Aurelia 2.0). We’re at the very, very beginning of the documentation part. We’ve got a professional technical writer who is going to be helping us on the docs. I’m wondering if you would be interested in getting involved in that effort. It would be a great way to provide a high impact/value for the community and make for a much stronger release of 2.0. If that sounds compelling to you, Let me know and I’ll point you to some things to look at. Thanks either way!

[baerrach]

@EisenbergEffect It's great you've got a tech writer, it was in the back of my mind to suggest one.
The first parts of the current documentation have a different feel than some of the later ones, and there are lots of "simply" type sentences that could get cleaned up that I just left alone.

Ideally I'd say yes, but I've got to start applying my understanding to our code base first before I get distracted with looking at v2.0 documentation, and we aren't ready to look at an upgrade yet.

[EisenbergEffect]

@baerrach Sounds good. Just know that the invitation is open :)

[bigopon]

@baerrach cool, thanks for the discovery and the suggestion. Our doc in this particular area is not great, as in not as great as it could be. Every example could have been with everything it requires, to make it absolutely clear what are being tested. But again, it's common across our doc, little mistakes here and there. So if you could help, as you suggested, it would be 🚀

[baerrach]

@EisenbergEffect

I'm at the stage where I'm learning stuff that isn't in the docs.

See https://discourse.aurelia.io/t/order-of-components-lifecycle-between-components-plus-router/2947/5

There is a gap between the learnings available in the documentation and actually applying those learnings.

Its made worse by the fact that UI/Front End development isn't my strong point.

I'm re-using anything I've picked up from other frameworks (like React) but all these docs suffer the same problem, that there isn't enough engineering advice to help solve specific problems and these are already solved problem: menu handling, where to put state, what values belong where (UI vs Domain vs State).

Ethically I can't lock up this knowledge, it just grates on my conscious.
Plus I'm bound to use it elsewhere so I want it to be available.

I also don't want this fragmented somewhere else, there are some great blogs out there but they've slowed down over the years and contain out dated information. I'd rather they were part of the Aurelia docs so they have a chance of being maintained, have some guidelines attached to how to document, etc.

However I think I'm stuck on vCurrent.

Who should I talk to to reconcile this?
Is there capacity in the team to cope with me adding more stuff into vCurrent?

[EisenbergEffect]

@baerrach Right now, the team is very heavily focused on v2. However, if you are interested and willing, I'd be more than happy to work with you to improve the v1 docs. We have a technical writer working with us on the v2 docs. We could also ask him to work with you on v1 as well. If that sounds interesting to you, then maybe a first step would be to create an issue that proposes some specific changes and/or additions. We can chat a bit in the issue and then when we feel we've got a mutual understanding, you can start submitting larger PRs to this repo. I can review and get our technical writer involved there as well. Once we merge, I can publish the content.

Let me know if that sounds interesting. Of course, we'd love to have you work with use on the v2 docs as well if you are interested. In the very least, we want to make sure that the improvements and additions you make in v1 find their way into v2 as well so future devs can benefit regardless of which version they are on.

Thanks again for your constant interest. I appreciate that this is important to you and you're willing to help do something about it. I'm more than happy to find a way that enables you to do that. Shoot me some ideas.