Hello there!
First of all i'd like to say that i'm super excited with this project! It's by far the most awesome front-end framework that i've seen in a long time!
I come from a backend background and i usually don't play nice with frontend standards, but i'm getting used to it...
I'd like to know how to use a separated .html file from the view, cause i can't deal with html and js in the same file, seems so dirty.... :(
What i'm looking for would be something like:
app.js
const choo = require('choo')
const app = choo()
app.model({
state: { title: 'Set the title' },
reducers: {
update: (action, state) => ({ title: action.value })
}
})
const mainTemplate = require('./template.html');
const mainView = (params, state, send) => choo.view(mainTemplate)
app.router((route) => [
route('/', mainView)
])
const tree = app.start()
document.body.appendChild(tree)
template.html
<main>
<h1>${state.title}</h1>
<input
type="text"
oninput=${(e) => send('update', { value: e.target.value })}>
</main>
is there anything similar to this?
best,
rafa
Theoretically you could write a browserify transform to convert what you have to valid JavaScript. It'd be difficult, brittle, and not something I'd recommend.
Passing anything to require that Node can't handle is something I recommend strongly against. It's great when your code can run in any environment. Implicit build steps make a lot of your workflow more difficult because every tool has to integrate with them, handle weird source maps, etc.
Node will happily handle tagged template strings so you can test some of your components purely in Node.
cause i can't deal with html and js in the same file, seems so dirty.... :(
You still have that in your example though: the only difference is that your JavaScript sprinkled inside the HTML isn't testable or lintable without transpiling. Assuming state and send are in scope and that you're inside a template tag _can_ work but it seems like it'll be a hassle to maintain. What happens when you want to require another module for your view?
@bendrucker so i guess this is more of "something i MUST get used to it"... :/
@rafaelamorim Believe me I know the feeling - there's some really awful code out there where JS generates HTML markdown and it starts to feel really unmaintainable. But here are some things to consider:
module.exports = (params, state, send) => {} wrapper around itExactly. Your view functions must return DOM elements but that's the only restriction. yo-yo is a convenient way to write view functions while still maintaining HTML-like syntax. You could use pure JavaScript to construct your view (https://github.com/shama/bel#use-withwithout-hyperx) but at the end of the day your views are real JavaScript.
In a framework like Angular, your views are a mix of HTML and JS, neither of which are valid on their own without the framework to compile them and bind change handlers.
With JSX, your views are a mix of valid JS and then invalid bits (the XML) that require transpilation.
With yo-yo (choo/html), your views return DOM elements. If an element is purely static, you can inline some HTML with fs.readFileSync and brfs and construct a node with that. The diffing doesn't care how you return an HTMLElement.
Yup, I fully agree with what @bendrucker and @timwis say.
@rafaelamorim has your question been answered? :grin:
YEP! it's a "get used to that kid" case ;)
Thanks to everyone that helped me out on that.
Keep on the awesome work guys! You guys rock!
Best,
Rafa
Most helpful comment
@rafaelamorim Believe me I know the feeling - there's some really awful code out there where JS generates HTML markdown and it starts to feel really unmaintainable. But here are some things to consider:
module.exports = (params, state, send) => {}wrapper around it