I have a few Bases where I’m updating Views relatively often, and doing everything through a GUI can get a bit tedious. Editing the YAML file directly gives me the ability to copy/paste between views, so I tend to do this when making larger updates. Sometimes I like to view the YAML to get a higher-level look at the current status of my base as well.
Proposed solution
Provide an option to view the YAML (“source”) view of a .base file. There’s currently an option to show the file in explorer, and I use that to then open the file in VS Code, but I’d like to have a way to switch between YAML and GUI view similar to other Markdown files in Obsidian.
Current workaround (optional)
At this point, it’s just right-clicking on the .base file, showing it in explorer, and opening it in a different editor.
Being able to view and edit a full raw .base file or certain “views” from within Obsidian would be great. My only concern is that I’d break it somehow poking around.
Maybe a “read-only” option/mode when first opening a raw .base?
When navigating bases, I am unable to find a way to “view the source”… instead I must open the program in another text editor. My usecase is that I would like to create a secondary view based on the first, which I’d be able to do if I could view source, copy paragraph and done.
Proposed solution
Enable the same integration we have with normal notes… using the shortcut or command palette to toggle live preview or source mode, would show the code for the base
Related feature requests (optional)
Allow the UI to “duplicate a view”… although I like the clean UX right now.
@ariehen I also am concerned that it might break if we edit it wrong. However, I don’t think this is a big issue. We already have direct source YAML editing via base blocks like this:
+1(00) – I feel like the people who would break bases won’t use it* . Make it only accessible via Source or something like that, but it is a little rough to have files we can’t get to the source code of even though everything else (and theoretically, quite a lot of non-Obsidian files) can be done within the program.
Especially when people are explaining how to do something via the syntax – and even the documentation talks through the syntax, without a good walkthrough of the basic UI and how to combine those two – and you’re looking at the formula editor like “…hmm”.
*unless it’s just by doing too-advanced functions, in which case, caveat …coder. If you’re doing coding beyond what the editor offers, there’s always a risk of breaking something, but there are a lot of ways you can break bases with what it allows, too. There’s always going to be a way to break something, but at a certain point that’s user error and they’re/we’re taking that risk - you can always slap a WE DON’T RECOMMEND THIS on it.
