Question 1

Can a voice command mutate data, and what stops it doing something I did not ask for?

Accepted Answer

Nothing built in, and the README says so plainly: commands execute immediately once their arguments are complete, and no confirmation dialog is added. What you get is your own gate, because commands are Ruby callbacks where you attach visible: and authorize:, and the example routes an archive through a Pundit-style policy check on the record. The advice is to start with navigation and actions you can safely expose to the authorized user, and to remember that page scopes are routing hints from the browser rather than authorization.

Question 2

What does Jev actually see, and does my key reach the browser?

Accepted Answer

The key never leaves the server: you supply it in the server environment and restart Rails. Jev receives only the commands available on the current page, which is what page scoping is for, and free-form interpretation is the only step that needs a key, since help selections work without one. Because matching is Jev-driven, the phrasing users speak is what it interprets, and typed arguments are extracted with your own regex extractors or asked for as follow-up prompts.

Question 3

Is this usable today, or do I need to wait for a gem release?

Accepted Answer

Build it yourself. The status is unreleased, the gem is not published to RubyGems, and installation currently means building a local copy from the source checkout and then using bundle install --local. After that it is a normal engine: add the gem, run the install generator, replace the initializer's example block rather than appending a second home command, and mount the widget before the closing body tag with csrf_meta_tags in the head.

Question 4

What does the shared cache requirement mean for production?

Accepted Answer

There is no runtime database, no migrations, no Node build and no CSS framework, but a short-lived execution cache is required. In development, a disabled NullStore falls back to a local MemoryStore, which is not what you want across processes, so production is documented as using a shared atomic cache that you configure before deploying. Everything else is engine-served assets, and the only other production-facing requirement is standard cookie sessions with CSRF protection, which an API-only app must enable.

Question 5

What do arguments and command results look like?

Accepted Answer

Arguments are typed and declared with extractors: :string, :enum with a values list, and :integer each take an extract lambda plus an optional validate and a prompt used when the phrasing is ambiguous, so saying "find users" asks for a term while "find users named Alex" goes straight there. Results come back as navigate, message, event or reload, each accepting an optional notify for a five-second completion notice without a reload.

Question 6

What does browser_actions actually discover, and what are its limits?

Accepted Answer

With browser_actions enabled the engine finds supported visible controls at command time, so you register no buttons in Ruby: click and navigate covers clicking by name, going back and scrolling to a section, and editing covers filling fields, selecting, checking and submitting. The README copy in our source is truncated mid-sentence in that list, so the remaining edit actions and the deployment notes are not documented here.

Question 7

Who owns transactions, idempotency and tenant scoping?

Accepted Answer

Your application does. Commands are Ruby callbacks running in the request controller, where main_app, current_user and your helpers are available, and your execute block calls your own operation such as Project#archive! through your own Pundit-style policy. The gem does not wrap transactions, tenant scoping or domain idempotency, and you return Result.reload after a mutation when the whole page should reflect the change.

Voice Control

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev community