• Concept -> Stream
• Component -> Element too much overlap with native Element, HTMLElement. Besides, keeping similarity to "web components" is desirable.
• Confluence -> Merge (it's shorter to write, and well-known word)
• Remove deprecated functions
• Add decorators for Stream and Nano (for future debugging insight implementation)
• New folder hierarchy: explicit folders for element/nano/stream/page. Remove artificial constraint of namespace/module. This will allow user to form their own structure.
• Disallow arrays to be used as values in 'connect'
• Deprecate objects used as values this will still be needed, so we can't remove it
• Merges that return undefined to be treated as undefined (i.e. there is no definition of data). Remove constraints parameter
• Navigate to use id when available, and fallback to pageId

Describe the bug
Tiden init on my machine fails. I assume this is a windows issue

To Reproduce
Run tiden init in an empty folder on a windows machine.

Expected behavior
All the necessary files and folders should be created.

Desktop (please complete the following information):
Windows 10

Additional context
(node:32076) UnhandledPromiseRejectionWarning: Error: EINVAL: invalid argument, mkdir 'C:\C:\Users\earshrd\Documents\tiden-test\app\components\template'

Is your feature request related to a problem? Please describe.
When running tiden upgrade outside a Tiden project, or inside a subfolder of a Tiden project, it breaks down.

Describe the solution you'd like
When in a subfolder : I'd like it to automatically find the root of the tiden project before running its script.
When not in a Tiden project: It should show a helpful message.

Describe the bug
using URL fragments "hash urls", the behavior differs from the use of regular pushState

To Reproduce

1. Create a page that match URL /#/page1 and another /#/page2
2. Add a touchable that navigates to page2 from page1.
3. Go to page1 and click the touchable
4. Click back-button

The URL will change back to /#/page1

Expected behavior
Nothing should happen (this is the case with regular pushState). In Tiden, URLs should not change automatically when browser popstate.

Streams

• storage (stringified & minified localStorage)
• page
• navigator (online)
• url
• audio not to be part of stdlib... will offer later as separate package

Describe the bug
Error message when try to start Tiden on MacOS, error detail as:

Watchman:  spawn watchman ENOENT
events.js:291
      throw er; // Unhandled 'error' event
      ^
Error: spawn watchman ENOENT

To Reproduce
Follow the instruct, run:

• npm install -g tiden
• tiden init
• tiden start

Expected behavior
Tiden should start successfully on port 1100

Screenshots

Desktop (please complete the following information):

• OS: MacOS Big Sur 11.5.2
• Browser: Safari
• Version: 14.1.2 (16611.3.10.1.6)

Smartphone (please complete the following information):

• Device: Macbook pro 2015
• OS: MacOS Big Sur 11.5.2
• Browser Safari
• Version: 14.1.2 (16611.3.10.1.6)

Additional context
Add any other context about the problem here.

Describe the bug
After upgrading to Tiden 0.1.0 and executing a CLI command it errored: express wasn't installed.

To Reproduce
Unknown.

Expected behavior
All dependencies should have been installed automatically.

Screenshots

Desktop (please complete the following information):

• OS: macOS

Additional context
Add any other context about the problem here.

Expose saga.run() so that devs can run arbitrary sagas directly from the console. Great for debugging, testing, etc.

As is often the case, many streams and nanos depend on the same stream. Earlier we've resolved the issue of starting a stream by placing it in the apps startup scripts. This works, but it has some drawbacks:

• Unused streams will still run
• Streams have to be started by nano tests. This is tedious and error-prone, as often a stream has its own dependencies (which are prone to change)

This idea mitigates these issues by:

• A stream may be started by any other stream, nano, or other
• Multiple instances of a stream is already forbidden, so if it is already running it should be safe to ignore starting a stream that has already been started

IF this gets implemented, then we'd have the following pros:

• A stream/nano declares what other streams it depends on (increased readability, understanding of the system)
• Tests don't need to explicitly startup dependencies before running nano
• Exporting a nano becomes trivial. The importing app only needs a reference to the nano. It will fire up depending streams (and their depending streams) automatically.

However, we also get the following cons:

• Every stream now has a hard dependency rather than a soft one. In situations where the Tiden app is split in several repositories then a stream cannot be used cross-repo. This might be a showstopper. Need more investigation.

or, alternate idea:

A stream is never started when it is run. Instead, it merely register its existence to Tiden. When Tiden sees any request made to the stream name, then it starts it up.

There are several situations where several apps can reside in the same Tiden runtime. These may be developed by separate teams, and even be located in separate repositories. In this scenario it would be nice if the nouns used in communication are namespaced so that collisions won't occur.

A few requirements for this:

1. Scoping: A namespaced app must be able to communicate with the global scope, and possibly "parent scopes". An idea might be to specify for each app what scopes it should include.
2. The reverse to [1] must be false. I.e., global scope should not be able to make requests to a child scope.
3. Shadowing must be dealt with in an apparent manner. I.e. a namespaced scope should never be allowed to use same noun as its parent scopes.
4. Option to create an anonymous scope. These should be generated at runtime and guaranteed to be unique.

This is a prerequisite for confluence merge based nanos. (edit: name was changed in #1 )

Tiden aims to be as native as possible. This means we will not be using NPM, Yarn, or such. While they do the heavy work of picking the correct versions and downloading them to your computer, they're not intended for ESM.

We'll need a system that supports hosting by third party, such as unpkg.com, as well as fetching from NPM registry and pad with ESM native modules.

An interesting article: https://medium.com/@joeldenning/an-esm-bundle-for-any-npm-package-5f850db0e04d

Also we should keep track of native import support for packages: https://github.com/WICG/import-maps

Describe the bug
A clear and concise description of what the bug is.
There is HTML Entities for < and > in markdown.

To Reproduce
Steps to reproduce the behavior:
go to https://tiden.js.org/api/connect

Expected behavior
A clear and concise description of what you expected to happen.
Instead of <h1> it should show <h1>

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
Currently, all CLI commands need to be performed in the root of the project. This is not intuitive when working in bigger projects and all releveant work is in a subfolder (that is, a sub namespace).

Describe the solution you'd like

when I'm in / or /app: Assume root
when I'm in /app/someNamespace: Assume someNamespace

Describe alternatives you've considered
None.

For 1.0, Tiden should offer a fully functional dev-server for showcasing all the various pieces. It should be adequate, but it does not need to do anything fancy for now. For that, see IDE (full version).

It should offer the following features:

• Demonstrating elements, nanos, and (at least showing) streams.
• Each demonstration should support several examples
• It should be capable of showing namespace/module/custom structure
• It should be hot-reloaded
• The demos should not have different styles for defining them (such as pre-tiden UI-demo vs App-nano-demo)

Describe the bug
when creating a new page using tiden create page myPage myNamespace/otherNamespace a new page is created. It works, but the id is wrong

const id = `one/two/myPage`

Expected behavior
The id should be:

const id = `myNamespace/otherNamespace/myPage`

Having a dependency on Watchman requires the user to install two things. It's a hurdle, and it slows down adoption. We would be better off if we could find a suitable alternative that can be installed with NPM.

Describe alternatives you've considered
There is the popular https://github.com/paulmillr/chokidar project. However, I'm not sure if it is efficient across all platforms. It must use native bindings on Linux and Mac in order to be suitable. That is, inotify on Linux, and fswatch on Mac. Also there's Windows... Needs to be investigated.

It is currently way outdated. A lot of things have been renamed.

Also OKRs should be clarified. Off the top of my head:

• Tiden is designed from the ground up to be distributed/sharded/multi-repo (whatever noun fits best). I should be able to have many of my pages in Repo1 along with nanos and elements, and have a "sub-app" in Repo2 which also has similar functionality, which both come together to make one single App. I should also be able to have a "core streams" repo that is included in two separate apps. For Tiden, flexibility is paramount.
• It should effectively utilize native web technology.
• And probably some more....

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

For Stone release, we'll only have a means to tell whether or not the browser did "something". There is no way of telling if it went forward, backward, or made a jump.

This is quite limiting.

For this issue:

• Determine strategy for managing the History API. It must be possible to use history the way the web usually does, but it must also be possible to override the standard and always have a predefined "back navigation path", irrespective of what navigation was done previously.
• Implement said strategy.

Is your feature request related to a problem? Please describe.
Currently when we want to run several nanos on the same page, often nested within each other, there's a lot of boilerplate code for settings things up. Many steps of createElement/appendChild, and the result is less than intuitive.

Describe the solution you'd like
It'd be nice if we could borrow inspiration from lit-html and develop a function that works similarly to their render.

Let's suppose we have a template nano, a main page nano, and a popup nano. What I'd like to see is something like:

const result = yield nanos`
  <template>
    <mainPage>
      <popup slot="popup"></popup>
    </mainPage>
  </template>
`

Note: These are not customElements. These are sagas, as any other nano. However, the concept is familiar to web users and more intuitive than many lines of javascript calls.

• The returned result should be the return value of the first nano that quits.
• All nanos should be automatically canceled when one returns. (we do this today using redux-saga's race function)

Describe alternatives you've considered

1. We could package nanos inside real customElements and use lit-html to render them. The result would look very much like a React container component.

Additional context
No matter what solution we go for, it is imperative that we can await the result from the nanos. This means that the sagas can't live free in the wild, but must be bound somehow to its creator.

Would be great if the system tests are automatically run on every PR and merge, on at least Linux, Mac, and Windows.

Describe the bug
Running init on a folder with files already in it, tiden still sets upp the new files. This has caused me to accidentally overwrite files. It is also annoying when accidentally doing this in your home directory!

To Reproduce

mkdir `/tmp/test` ; cd /tmp/test
touch "hello.txt"
tiden init test

It creates a bunch of files.

Expected behavior
It should refuse, clearly stating that init can only be run on empty directories

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Describe the bug
When two streams make requests from each other, either directly or indirectly by third party, an endless loop can occur which causes the app to freeze, or downloads to happen perpetually.

To Reproduce
Create two streams. Make stream1 fetch something from stream2, and then stream2 should fetch from stream1. Witness madness and chaos occur.

You may also insert an intermediate stream(s), such that stream1 -> stream2 -> stream3 -> stream1

Expected behavior
After 3 rounds Tiden should crash the first offending stream, and provide an error message

Desktop (please complete the following information):
all

Smartphone (please complete the following information):
all

Additional context
As discussed in #14

For this version, the CLI interface should handle this (at a minimum)

• Initiate a new Tiden project
• Create stream
• Create nano
• Create namespace
• Create elements components
• Moving/Removing of all above to be done in #36

• Article
• Video
• Code examples

All available on GH pages

• 1. IDE actions
• 2. Built-in editor
• 3. Insight
• 4. Nano builder

1. IDE actions

Any CLI command should also be possible to do from within the IDE.

2. Built-in editor

Live editing of streams, nanos, and components from within the IDE.

3. Insight

Powerful logging. In some way, it should be possible to visualize the communication end-to-end from i.e. component -> nano -> otherNano -> stream -> upstream.

We should also be able to however over a component and have the option to list its current property values. A means to visualize the chain might be suitable here.

4. Nano builder

For standardized nanos, it should be possible to drag & drop streams into it, merging them, and selecting property values. Consider the schematic view of plumbing for this.

For deployment of Tiden

For efficient testing, we need the means to replace a stream live.

As all streams are named, we could introduce a new API method that first kills of the previous stream and then starts up a new stream. This would be a good way to mock them.

This relates to #14

• References to external documentation (Saga, Haunted, CustomElements, Shadow DOM, etc.)
• Philosophy
• Concepts

Describe the bug
Names for components, nanos, and streams should be camelCase. However, if snake-case is used, then it will happily perform the action anyway, leading to broken code.

To Reproduce
tiden create component sidebar-tutorial
tiden create nano sidebar-tutorial
tiden create stream sidebar-tutorial
tiden create page sidebar-tutorial

Expected behavior
It should fail with a clear error message

We currently only have the ability to create stuff. We'll need a means to (re)move them as well.

Originally described in #3

Investigate widely available options for hosting and add an entry in the documentation for how to deploy.

Also, let's use the best option for hosting our own docs website. It will be a good showcase for all those "bundler lovers".