3 ms·
Skimmed through the docs. Some thoughts: - it has a bunch of useful serialization sugar (e.g. `{{ classes }}` serializes correctly whether it's an array, an ob
by lhorie 6y ago
Skimmed through the docs. Some thoughts:
- it has a bunch of useful serialization sugar (e.g. `{{ classes }}` serializes correctly whether it's an array, an object of booleans, etc. This is similar to Angular (in React-land, this got pulled out into a separate package, classnames). There's similar sugar for `style` and objects (which React also supports).
- I'm not a fan of the variadic event handler signature. If I understand correctly, having a event handler inside a loop adds an extra argument to the handler function, but what happens if there are nested loops? In React-land, this would be done w/ arrow functions and closures; in Angular, one would write a js function call similar to plain HTML event handlers. I prefer the React approach (though I understand that isn't really an option for the way you approached synergyjs)
- Similarly, if `#` is bound to loop index, then how do you access outer loop index in a nested loop situation?
- Binding view property names to form controls of the same name is an interesting abstraction. React looks clunky in comparison (yes, even hooks). Angular has a similar facility, with the addition of allowing custom transformation logic (think getter/setters for bidirectional bindings).
- prerendering via a browser-like environment isn't the best approach IMHO (I've seen people run into issues w/ jsdom missing features, for example, and something like puppeteer is a bit of a heavy thing to be running frequently server-side)
- I like the clear separation between JS and CSS (but, then again, I'm an old school person). React people might dislike it if they're used to css-in-js per-component style encapsulation.
Overall impression: appears to pack quite a punch for 4kb (more so than Preact IMHO, because of how it handles forms). Docs are clear and to the point, but could use more examples/tutorials (especially lifecycle hooks). Would like to see it mature a bit (e.g. in terms of addressing things like nested loops, as mentioned above), and I think it would benefit from considering a less expensive SSR approach.
Very promising!
- defx 6y agoFirstly, thank you so much, this kind of feedback is extremely useful and greatly appreciated. I'll try to reply separately to each of your points for clarity...
- defx 6y agoRE the event signature: (If you raise an event from an item within a repeated block then synergy provides the data for that item as the second argument to your event handler function.) If you have a nested loop then you'll get the data item for that particular loop.
- lhorie 6y agoRight, sorry I think I wasn't clear. I'm wondering how one goes about something like this as.map(a => <tr>{ bs.map(b => <td onClick={() => foo(a, b)}></td>) }</tr> ) Notice how both `a` and `b` are passed into `foo`. There are other possible permutations, such as passing indices or properties of items. I believe it's possible to access `b.bar` easily enough, but it wasn't clear how to access `a` or the index of `as.map` from inside the inner loop.
- defx 6y agosee the comment above "RE: #" concerning the index. synergy doesn't provide means for you to pass custom arguments into the event handlers, but the event target and the datum provide context of the loop and the handlers "this" is the viewmodel itself.
- defx 6y agoRe the '#', yes - this is currently a limitation and will be addressed, most likely with destructuring syntax for the repeated block declaration (e.g., #each [i, item] in items)
- defx 6y agoRE prerendering: yes, completely agree - puppeteer would certainly be heavy for dynamic SSR and I wouldn't suggest that. Perfectly suitable for build-time prerendering though, which is what I've been focused on so far in this area with Synergy.
- defx 6y agoRE separation of concerns: Glad you like it, and yeah - the react approach is very popular so this won't suit everybody, but that's fine...people have different styles and I don't believe there's a one "right" way any more than there's a "best" programming language.
- defx 6y agoRE css-in-js style encapsulation: One of my goals was to support pre-rendering, which is why Synergy doesn't currently use Shadow DOM. In the (hopefully near) future, Shadow DOM will become declarative and at that point Synergy will adopt whichever pattern the web lands on and be able to provide both features.
- defx 6y agoRE docs: Yes absolutely! The next section in the docs will be tutorials and all of this great feedback will be most useful in helping figure out what to focus on so thanks again.