4 ms·

Yes, it would be simplificantly simpler to edit html if it wasn't stuck in between two strings, for one, let alone inside an array. todo.view = function(ctrl)

• deleted 13y ago
  [deleted]
• danneu 13y ago
  > Yes, it would be simplificantly simpler to edit html > if it wasn't stuck in between two strings > ... > m("body class='application", ... You would put attributes in an object. m("body", {class: "application"}, [ ... ]) Sure, it's no Lisp, but to me it's just Javascript's commas that suck the thunder out of it.
  • insin 13y ago
    This is exactly why JSX is such a big win for this method of creating content - it's just sugar for the same function calls, but expressed in a form we're already used to multiply-nesting, with closing tags to help keep context and no need for commas when you need to break a line. Quite neat that you can use it for non-React stuff just by tweaking the pragma comment the JSX transformer requires. Here's an actual example of a Bootstrap table in a React component using JSX: https://github.com/insin/lifequote/blob/master/src/components/steps/QuoteInfo.jsx https://github.com/insin/lifequote/blob/master/src/component... There's not much display logic in it, so it doesn't exhibit the usual progression I've seen when writing React components so far, in which most display logic happens up-front in a component's render() and often gets moved into another method and called directly from where it's going to go in the structure being returned from render(), so you generally don't end up with huge whacks of JSX in components which are doing more work.
    • chc 13y ago
      To be clear, my example wouldn't actually work. I had a brain fart about JSX's output format. Sorry about that. I do think it would be pretty easy to adapt it to this format, though (it looks like you'd just need to change one line in the visitReactTag() function).
      • zpao 13y ago
        You could actually do this without a single change to the JSX transform, and instead just make a simple object that calls m() with the right params. Then you just change the @jsx pragma to point at that object. With a complete array of elements this should mostly work. ```js / @jsx m.dom */ function m(type, props, children) { // assuming m() looks something like this. return { type: type, props: props, children: children}; } m.render = function(lwDOM){ console.log(lwDOM)}; m.dom = {}; // React hard codes this array so we can do something like this to build the mapping ['a', 'span'].forEach((el) => { m.dom[el] = function(props, ...args) { return m.call(null, el, props, args); } }); m.render( <a href={"google.com"}> <span>hello</span> <span>world</span> </a> ); ```
• lhorie 13y ago
  I think you're too caught up on syntax and missing the big picture. The m() method is simply a helper utility that returns a POJO. You can write the code in coffeescript if js syntax bother you, or you can go nuclear and implement a frontend or a preprocessor that take some popular templating syntax and spit out the appropriate data structure. The conversion tool I provide is a small step in that direction, but, with Mithril being at a mere v0.1, it still needs more work done to be fully automated. Also, just FYI, the selector syntax follows CSS rules, so you'd write m("body.application"), not m("body class='application'")
  • ulisesrmzroche 13y ago
    Programs are for humans to read and only incidentally for computers to execute. Syntax is the whole picture.
    • lhorie 13y ago
      Well, I already told you which directions Mithril can go in terms of making syntax more to your liking. If you're too put off by js templates and not willing to spend time helping push the project in a direction you like, you can always try other frameworks or come back later when I have a more HTMLy frontend option available.