An attempt to write todolist with weex Vanilla

Time:2020-1-14

How to write a page with vanilla code on weex has been described in the previous article:
https://hashnode.com/post/run…
In general, you can refer to this demo, which is actually some DOM operations,
https://github.com/alibaba/we…
So I made it clear that weex does have a DOM API,
And this API should be the basis of all weex based frameworks, such as weex, rax, and even if there is an angular version

In the weex warehouse, you can see that there are currently four frameworks, among which there is no framework for vanilla,
https://github.com/apache/inc…
But actually this code is out of date, like laterweexGlobal variables are not completed,
So in order to facilitate my local development, I developed a version based on Vue fork for testing,
https://gist.github.com/jiyin…
The pilot project can be seen from GitHub, and the todolist generated with a single file:
https://github.com/mvc-works/…
Final interface:

An attempt to write todolist with weex Vanilla

In this todolinist, I have implemented the basic functions of adding, deleting and modifying, but obviously the following functions are true:

  • Clear read tasks

  • sort

It’s not because it’s too difficult to achieve. Although it’s not that difficult, it’s the main purpose of the test project,
I will mainly test whether weex’s DOM API can write decent pages in the future,
After simple encapsulation, the writing method of DOM part is very clear in coffeespcript,


# DOM tree

mainTree = ->
  div style: styleBody,
    div style: styleContainer,
      div style: styleHeader,
        input
          ref: 'input'
          style: styleInput
          attr: {value: '', placeholder: 'Some task...'}
          event: {input: onDraft}
        text
          style: styleButton
          attr: {value: 'Add task'}
          event: {click: onAdd}
      text
        ref: 'raw'
        attr: {value: getRaw()}
        style: styleContent
      div
        ref: 'content'
        style: styleContent

# mounting document

doc.documentElement.appendChild (helicalExpandTree mainTree())

Familiar with DOM operation, you should be able to fill out my code:

helicalExpandTree = (tree) ->
  # console.log '\n\nExpanding:', JSON.stringify(tree)
  [name, props, children] = tree
  element = doc.createElement name,
    style: props.style
    attr: props.attr
  if props.event
    for key, value of props.event
      element.addEvent key, value
  if children?
    # console.log 'CHILDREN:', JSON.stringify(children)
    for child in children
      childElement = helicalExpandTree child
      # console.log '\n\nChild to append:', JSON.stringify(childElement)
      element.appendChild childElement
  if props.ref?
    domRefs[props.ref] = element
  element

Then there’s event handling, which is a bit problematic. In fact, there are two places to deal with: model and view,
Students familiar with jQuery should be able to guess that they need to pass theevent.targetDo DOM operation,
Both sides deal with it to ensure that there is no inconsistency on the interface. Of course, it’s wordy and poorly maintainable,

onRemove = (taskId) -> (event) ->
  store.tasks = store.tasks.filter (task) -> task.id isnt taskId
  # DOM operations
  taskElement = event.target.parentNode
  taskElement.parentNode.removeChild taskElement
  modifyRaw()

If there are tabs in the page, the state management between tabs will make the page very complex,
Of course, for convenience, I imitated react’srefThe write method is used to specify a specific reference to the dom,
In this way, there is no need to use jQuery to select DOM nodes in small pages
So it seems that the whole page can run smoothly, although the effect is really strange


onAdd = (event) ->
  newTask = id: getId(), done: 'false', text: store.draft
  store.draft = ''
  store.tasks.unshift newTask
  # DOM operations
  console.log 'DOM operations!!!'
  domRefs.input.setAttr 'value', ''
  newElement = helicalExpandTree (taskTree newTask)
  console.log '\nnewElement:', newElement
  domRefs.content.appendChild newElement
  modifyRaw()

In fact, we can reflect on whether Vue react is suitable for mobile terminals,
These frameworks can be used to build single page apps for desktop platforms,
With a variety of state management, componentization, DSL, programming style in it, as well as various development tools,
The main thing is that declarative writing really improves development speed and component reuse
However, the state management of mobile phone is not as complicated as that of desktop, which does not need the strong function of react

The operation methods of handwritten DOM are basically inefficient and poorly maintainable, and so on,
Except for writing almost static pages, this scheme can be thrown into the wastebasket of history
However, it also has the advantage that there is not much abstraction, the page starts very quickly and the submission is very small
Although weex has been running in a JS runtime, there is little overhead in initializing components
It may be tiny… But in theory, there is always a difference in the code that needs to be executed during the startup process

Of course, it’s almost useless to write like this in general, just to prove that the native DOM API can work normally:
http://weex.apache.org/refere…
There is no clear point of view, just think about some problems in writing weex