Comments (7)
Thanks! I'm glad it has helped!
I felt like there is truth to #36 but I wasn't sure what the solution was.
To help me understand you better, could you answer these questions?
- how much did you read before you started to feel that way (e.g. wanting to build a real component and finding the current approach unsatisfactory / something that added unneeded friction to your goal)? Perhaps stated differently, when did you first want to descaffold the scaffolding code?
- how far into the repo have you currently read so far?
However, the standard component type hardly fits in my short-term memory, and it's positional (ie not using a record). Your scaffolding really makes it a lot easier at first, but it suffers from the problem of it being harder to learn "the real way", if that's what you're after later β so I'm advocating for gradual ramp-up with simple real-world components of increasing complexity.
It might help for me to provide some context. The Halogen v4 docs worked exactly like you described above. The first example was a simple toggle button example. It then proceeded to add examples that covered more complicated parts. That's what I used to learn Halogen. However, after learning it, I thought that the approach being top-down quickly overwhelmed a new learner. I proposed a bottom-up approach and submitted a PR that didn't get merged. As time went on and Halogen v5 came out, I decided to port that PR over to this project and update it to v5. I think your comment and the one made in the other issue is highlighting the issues that arise when using this approach.
If I'm reading you correctly, it sounds like you're suggesting that I have both a scaffolded version and non-scaffolded version of each example. Thus, when one is initially learning, they will refer to the scaffolded version. Once they feel competent/confident enough, they can look at a real component that provides a good example without having to go through the mental acrobatics of descaffolding the scaffolding code.
If so, I think that makes sense and seems like a good solution to this problem.
Could you submit a PR where you do this with a very simple example, so we can see how that looks and further discuss issues that might arise with this idea in that PR?
from learn-halogen.
- how much did you read before you started to feel that way (e.g. wanting to build a real component and finding the current approach unsatisfactory / something that added unneeded friction to your goal)? Perhaps stated differently, when did you first want to descaffold the scaffolding code?
Once I got up to the parent/child section, which I found kind of confusing at first because it seems to go from smoothly ramping-up connecting everything to extremely complicated, missing bits, straight away.
- how far into the repo have you currently read so far?
I've read the whole thing (a few times, just to make sure).
If I'm reading you correctly, it sounds like you're suggesting that I have both a scaffolded version and non-scaffolded version of each example. Thus, when one is initially learning, they will refer to the scaffolded version. Once they feel competent/confident enough, they can look at a real component that provides a good example without having to go through the mental acrobatics of descaffolding the scaffolding code.
If so, I think that makes sense and seems like a good solution to this problem.
It might be a good solution. I'm not sure, really. I should really have thought more about the issues I had before commenting. I left it for a few days, but I was quite keen to roll my sleeves up build something complicated, and I thought you might like to know the feedback.
Could you submit a PR where you do this with a very simple example, so we can see how that looks and further discuss issues that might arise with this idea in that PR?
Yes, you've understood what I meant perfectly. I'm working on a PR now.
from learn-halogen.
PR request: #43
from learn-halogen.
You know... looking at the examples in the source for halogen, maybe it's just enough to point people at that when they're at that point? What do you think? It's almost what I'm talking about, except that again, there, they get complicated really fast. I guess what would be great is something like the intro material the reagent
library in clojurescript
has. Not sure if you've seen it: https://reagent-project.github.io β a bunch of real-ish examples that get progressively more involved, but where it's not pulling any punches, but still small enough, which are explained and you can learn from.
from learn-halogen.
Once I got up to the parent/child section, which I found kind of confusing at first because it seems to go from smoothly ramping-up connecting everything to extremely complicated, missing bits, straight away.
Maybe this is another issue at heart here...?
I've read the whole thing (a few times, just to make sure).
I was quite keen to roll my sleeves up build something complicated, and I thought you might like to know the feedback.
Thanks for answering my question. I was wondering whether you had gotten to the template file yet and was giving this feedback without that knowledge.
And yeah, I appreciate the feedback.
You know... looking at the examples in the source for halogen, maybe it's just enough to point people at that when they're at that point? What do you think? It's almost what I'm talking about, except that again, there, they get complicated really fast.
So, perhaps this repo just needs more "real world" examples that build progressively and use less scaffolding (or inline it) after we hit the parent/child part?
I'm going to look at your PR now.
from learn-halogen.
Yeah that sounds great... (the real world stuff). I added this to the PR, which I'll quote here:
I suppose the core issue I have is that the docs and examples in the docs don't clearly explain what all the pieces are in one place, so your document has this decided advantage of being able to isolate complexity... yet it seems the material has a few gaps, as you point out in #42 β once we've gone through the simple examples, maybe we need a point where they can decide to either continue with more examples and slowly introduce the more tricky/real-world types (for example, adding state, then adding passed-in state (ie
input
), then when actions come into the picture) then parents, then children, then passing state between them, then querying, then parents & children components, slowly lifting the training wheels off as we go?
from learn-halogen.
Nice. #45 is great :)
from learn-halogen.
Related Issues (20)
- `--no-minify` is not supported by `serve` action of `parcel` HOT 4
- Link to 'Styling Question' and its links
- Update project to 0.13.4 PS release
- log element's text? HOT 2
- Upgrade project to PS 0.13.5
- Upgrade project to Spago 0.12.1
- Add CI build for local-based installation
- Whatβs best practice/pattern for cross component communication HOT 1
- Add tip from Gary for rendering valid/invalid input data
- Add exercises for each example HOT 7
- launchAff_ vs runHalogenAff HOT 2
- Const Void or Const Unit for unused Query HOT 8
- Link to 'template repo' for Halogen
- Recommend spago's --watch feature in automatic reload instructions HOT 6
- Integrate examples with `halogen-storybook`
- Change `purescript-jordans-reference` links to use its `latestRelease` branch? HOT 6
- Which to cover first? Halogen Hooks or Halogen Components? HOT 9
- use forall instead of Void for empty queries, messages, inputs HOT 1
- Link to statebox's fork of halogen-svg
- Feature Request: convert to mdBook HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from learn-halogen.